So you don't prevent MITM attacks...it's still a step up from cleartext.
All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated. For authenticated communication, we continue to have what HTTPS is today.
The main issue is retraining people to not think that "https" means "safe". That's something that browsers are already good at, however, because there is already a world of difference between the user experiences of visiting a site with a trusted cert and visiting a site with an untrusted cert.
It's not a meaningful step up from cleartext, because a passive attacker can become an active attacker with just a couple spoofed packets or control of a single DNS resolver.
It is a meaningful step up, because the passive attack is entirely risk free for the attacker, while an active attack carries with it the risk of detection.
The practicality of enormous secret drag-net operations like the NSA has been running would decrease dramatically if TLS had been the norm rather than the exception, even with unverified certificates. You can't opportunistically MITM 100% of connections without somebody noticing.
It is a shame that cleartext connections have to be the out-of-the-box default in every web server. Security should be the default, and I think the CA mess is to blame for that not being the case.
The sane thing to do would be generating a random self-signed certificate if the administrator didn't set up any explicit certificates. That would prevent passive attacks, and can be built on top of with technologies like certificate pinning and Convergence to mitigate active attacks.
Not entirely. I kind of agree. I think I even posted a nearly identical comment once.
It would be nice if there were two kinds of connections. Encrypted unauth and encrypted auth. That seems strictly better than offering unencrypted connections. Your browser could still display the "wide open to attack" icon for encrypted unauth if you like.
The entire reason people think TLS should have "unauthenticated encryption" (which is in the literature kind of an oxymoron) is that they don't like the SSL CAs.
I don't like them either.
But the SSL CAs are a UI issue. Instead of dinking around with the browser UI to make worthless "unauthenticated encryption" sessions appear different, why not just build a UI for TACK, let people sign their own certificates if they want, but then pin them in browsers so those sites can rely on key continuity instead of nothing.
Five years from now, if TACK pinning becomes the norm, I think it's a safe prediction that basic TLS certificates will be free from multiple vendors. Moreover, the corruption of the CA system will matter less, because unauthorized certificates will violate pins and be detected; the CAs that issue them can be evicted.
While we're at it, why don't we just fix the UI for managing CA roots? It hasn't changed since the mid-1990s.
I am baffled by why anyone would actively promote an insecure cryptosystem as a cure for UI problems, or even as an alternative for some entirely new cryptosystem like MinimaLT.
All of these things are simply gated on browser vendors. That's the overhead. Why would you push for a new UI for insecure connections when you could instead lobby for TACK?
This tradeoff is easy. UI that makes unauthenticated connections easier to accept is a bad idea; UI that makes certificate pinning work better is a good idea. Suggested tradeoff: pursue good idea, avoid bad idea.
> All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated.
This is a perfect example of <strikethrough>"good enough is the enemy of good"</strikethrough> "not completely broken in every possible way is the enemy of barely good enough" that is so prevalent in web security. If we don't use this chance we have now to secure internet traffic we will continue to be completely vulnerable to rogue WiFi AP like http://www.troyhunt.com/2013/04/the-beginners-guide-to-break... and to companies as well as countries snooping their employers/citizens traffic via huge proxies for years to come.
All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated. For authenticated communication, we continue to have what HTTPS is today.
The main issue is retraining people to not think that "https" means "safe". That's something that browsers are already good at, however, because there is already a world of difference between the user experiences of visiting a site with a trusted cert and visiting a site with an untrusted cert.