Security Theater Everywhere strikes again. Unless you're logged in and entering data, Hacker News does not need SSL.
As a user of HN, I appreciate these security features. Suggesting that HN should not use HTTPS so that someone can access it from a 10 year old device that's impractical for modern web browsing anyways is possibly the weakest argument you can make against HTTPS.
[1] http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...
[2] http://justinsomnia.org/2012/04/hotel-wifi-javascript-inject...
It's basically a private key we're all assigned at birth that can't be rotated. It was originally meant to be used in the state-sponsored welfare program "social security", but tons of businesses require it as a unique identifier.
Absolute stupidity on all fronts.
For example:
http://www.identityhawk.com/Who-Can-Lawfully-Request-My-Soci...
Sadly, it's too late in the day for me to try to parse this: http://www.justice.gov/opcl/social-security-number-usage
Without SSL, you can't be sure of the integrity of the data set by the site. It's important even when not exchanging private data.
You say they can guess what you're looking at with HTTPS.. well if you use SRI without HTTPS, then they don't need to guess.. they absolutely know what you're looking at.
Also, if they can change the page (which they can if it's over http), they can change the hash as well.
Also, SRI is like 9 months old since the first draft... which means it does nothing for the visitor unless they are using the newest version of one of the major browsers.
And I think, of the browsers that do support SRI (possibly in prerelease versions or behind feature flags), they require the page to be delivered over SSL anyway.
Take a look at that HTTPS certificate that you think means you're talking to the site of your choice. If it says "cloudflare.com", "incapsula.com", "edgecastcdn.com", "palmwebservices.com", "cdnetworks.net", there is a man in the middle of your HTTPS connection. This is the case for at least 38,000 sites we know about. There are probably more. (The list: http://john-nagle.github.io/certscan/whoamitalkingto04.pdf)
HTTPS Everywhere was well-intentioned, but the people behind it didn't realize that high-volume use of HTTPS forced less secure use of HTTPS. That's why it's a form of security theater.
I still trust the link between CloudFlare and Hacker News more than I trust the link between a dodgy ISP and Hacker News. Further, there's no reason that a CDN can't use SSL to the backend, so in that case the only weak point is the CDN and the original site, not any of the links.
Using HTTPS to a CDN is still far better than using HTTP to a CDN or to the original site.
Nothing forces sites to use a CDN. HTTPS, by itself, does not massively increase load. If the limiting factor of your web server is how fast you can do cryptographic operations for HTTPS, you're doing rather well; most of the time that won't be your limiting factor.
Using a CDN is not wildly less secure than using a hosting service, and numerous sites use hosting services. "Secure to the CDN" is still a net improvement over "completely insecure".
By all means, complain about sites using a CDN that you don't trust. That's not an argument against universal adoption of HTTPS, though.
HTTPS does not break caches; that's FUD. Browsers can cache
HTTPS pages just fine
Proxies are not a common setup; approximately zero home users use them, and a subset of corporate networks do (only the obnoxious ones).
In any case, caching proxies are far less important than caching browsers, and HTTPS does not in any way break caching browsers.
Even with CDN terminating SSL, it protects you from injected malware and ADs between you and the CDN by your ISP.
If you want to work on a spec to make cacheable, signed hypertext documents, I will be totally down for helping. But no such spec exists today.
Unless my understanding of SRI is totally wrong, it is to protect against malicious changes to third-party resources, usually by the hosts of those resources (or someone attacking them) or a poisoned cache thereof, not to guard against MITM.
Subresource integrity can protect against changes done on the server, while TLS can protect against changes done by a man-in-the-middle. They protect against different things, and do not significantly overlap.
For example, example.com (delivered over HTTPS) could use jquery, and include in the page it delivers to you both the URL and a hash of the jquery scripts; you could then fetch those scripts over untrusted channels or from untrusted servers, and be sure that they are the ones that the administrators of example.com intended to reference. If example.com were not using HTTPS at all, then they could just be the resources that the Man In The Middle of your channel to example.com intended you to see.
So, how you defend "SSL everywhere".. I don't buy it. I feel more for what the commenter you responded to said, because your counter argument comes with a lot of assumptions that have more problematic implications. A false sense of being secure does seem much worse than knowing that most of the stuff you do is actually insecure to begin with.
Plain text is not a bug. It's a feature! Cheesy, I know.
It may feel so, but it certainly isn't. Some security (against anyone but the top 0.X% of "bad guys") is certainly better than no security (random script kiddie in your coffee shop injecting 0-days from exploit-db straight to your browser).
And regarding the hopelessness of SSL/TLS - the CA problem exists and is pretty huge. But we know the solution[1]: it's called certificate pinning. When you control clients (Google/Chrom[e/ium]) can just pin your own certs/CA and refuse anything signed by the Hong Kong office. For the rest of us that don't, there's HSTS (to tell the browser to refuse http:// redirects from a MiTM, overriding TLS altogether) and Public Key Pinning Extension (HPKP). They aren't very widely rolled out, but we're getting there. Test your browser here[2], you may be surprised. This all assumes that the user won't ignore the warnings when they come up, of course. Also it would protect you from your second visit onwards - if you're being MiTM'ed at your first attempt to grab a site with all the above bells and whistles, your browser doesn't know about the pinned stuff yet, so it is vulnerable to SSL stripping, etc.
In short, it's certainly better than nothing (protecting you from 99%+ of bad guys) and we're slowly fixing it[3]. Don't let the man get you down.
[1] Until we get to a proper, more distributed solution
[2] https://projects.dm.id.lv/Public-Key-Pins_test
[3] Shamefully slowly - TACK was proposed so long ago... https://news.ycombinator.com/item?id=4010711
What about if you're in a country that likes to censor the news?
However, after the first visit, your browser learns through HSTS (the Strict-Transport-Security header) that accessing news.ycombinator.com without TLS is not supported, and won't attempt to access it again except via TLS. (For a year, in HN's case - this is configurable by the site administrator.)