If only it were that simple. As it stands now, the problem with HTTP/HTTPS is that encryption is an all-or-nothing proposition. There should be three modes supported:
1. Unencrypted (for casual/ad-hoc web servers serving cache-able static assets)
2. Encrypted-untrusted (for casual/ad-hoc web servers that just want to thwart basic Wi-Fi cookie sniffing)
3. Encrypted-trusted (for most established websites)
Right now, #2 isn't a viable option, because HTTPS servers with self-signed certificates are correctly treated as dangerous. A URL that designates the HTTPS protocol must always require a trusted connection.
The solution is (relatively) simple: HTTP 2.0 should allow encrypted-untrusted connections for URLs designated with the HTTP protocol.
Exactly: I believe that's actually the plan from browser-makers, that the "S" designates not whether you want to use encryption, but whether the encryption will be required to be trusted. We'll see what actually happens.
Going forward hopefully TLS 1.3 or a later version will be able to encrypt enough of the exchange that a passive sniffer can't necessarily tell between 2 or 3 - hopefully they won't be able to see the certificate, or there'll be a way to negotiate an anonymous DH as a minimum that an attacker cannot observe (without that in place right now, I've argued against aDH remaining in TLS 1.3).
Is encrypted-untrusted really a good idea? MITM attacks over wifi are nearly as easy as cookie sniffing. What sort of sites would fit into this category?
Absolutely everywhere you use HTTP now. It's never worse than plaintext, and it's an effective replacement for it.
Encrypted-untrusted prevents mass passive surveillance, and requires it to be active MITM. And - as I've pointed out on the TLS WG list a few times - if an attacker can't tell you're being opportunistic, they might not be willing to risk being detected. We can make them take that risk by reducing the visible distinguishers there.
Sorry, maybe I wasn't clear... With encrypted-trusted if you try an MITM, unless you have a valid SSL key, the browser will show a big error screen and not send any cookies. With encrypted-untrusted the browser wouldn't do that, so the cookies would still be sent. You don't even need to route the connection, you could just present an "Error connection to server" page and most users would just think the wifi isn't working.
My question is given that what is the purpose of encrypted-untrusted? It's no more secure than HTTP for anything that uses session cookies or the like. Sure the connection is encrypted, but then all you are doing is stopping people seeing that you are accessing My Little Pony shows on YouTube. If it's a public hotspot at the coffee shop, they can probably see you watching it (IRL) anyway. Given the connection is untrusted, it wouldn't be hard for the NSA to do a MITM attack at the ISP level.
Thanks, that makes sense. As long as people understand that although it's encrypted it's still not really safe. That could be the hard part though, as I expect a lot of people assume anything encrypted is safe (related, see malicious SHA1 - https://news.ycombinator.com/item?id=8136526).
Here's one extremely important use-case for #2: router/server admin interfaces. For most people it's out of the question to deal with certificates here, but the advantages of end-to-end encryption are still obvious.
That's just one example, of course. There are countless others.
#3 can't be spun up on an ad-hoc basis. It requires a domain name and a signed certificate. This costs time and/or money, and simply isn't feasible for the smallest websites.
#2 can allow the most simple web server instance created in five minutes to be guarded against passive snooping by governments and hackers.
1. Unencrypted (for casual/ad-hoc web servers serving cache-able static assets)
2. Encrypted-untrusted (for casual/ad-hoc web servers that just want to thwart basic Wi-Fi cookie sniffing)
3. Encrypted-trusted (for most established websites)
Right now, #2 isn't a viable option, because HTTPS servers with self-signed certificates are correctly treated as dangerous. A URL that designates the HTTPS protocol must always require a trusted connection.
The solution is (relatively) simple: HTTP 2.0 should allow encrypted-untrusted connections for URLs designated with the HTTP protocol.