PHK: HTTP 2.0 Should Be Scrapped 220
Via the HTTP working group list comes a post from Poul-Henning Kamp proposing that HTTP 2.0 (as it exists now) never be released after the plan of adopting Google's SPDY protocol with minor changes revealed flaws that SPDY/HTTP 2.0 will not address. Quoting: "The WG took the prototype SPDY was, before even completing its
previous assignment, and wasted a lot of time and effort trying to
goldplate over the warts and mistakes in it.
And rather than 'ohh, we get HTTP/2.0 almost for free', we found
out that there are numerous hard problems that SPDY doesn't even
get close to solving, and that we will need to make some simplifications
in the evolved HTTP concept if we ever want to solve them. ...
Wouldn't we get a better result from taking a much deeper look
at the current cryptographic and privacy situation, rather than
publish a protocol with a cryptographic band-aid which doesn't solve
the problems and gets in the way in many applications ? ...
Isn't publishing HTTP/2.0 as a 'place-holder' is just a waste of
everybody's time, and a needless code churn, leading to increased
risk of security exposures and failure for no significant gains ?"
Re:Encryption (Score:5, Informative)
Last I heard, it still supports unencrypted, but only if both the client and server ask for it. If either one asks for encryption, then the connection is encrypted, even if there's no authentication (i.e. certificate). With no certificate, it's still possible to pull an active(MitM) attack, which is much harder to pull off at a large scale without anyone noticing (i.e. you can just collect all data you see).
Re:Encryption (Score:4, Informative)
Nonsense. Enforcing encryption does not make things more secure, unless that encryption and the authentication going with it is flawless. That is very unlikely to be the case against an attacker like the NSA.
Re:Encryption (Score:5, Informative)
Last I heard, it still supports unencrypted, but only if both the client and server ask for it. If either one asks for encryption, then the connection is encrypted, even if there's no authentication (i.e. certificate). With no certificate, it's still possible to pull an active(MitM) attack, which is much harder to pull off at a large scale without anyone noticing (i.e. you can just collect all data you see).
A server cannot ask for encryption.
Unless the client establishes a secure connection in the first place, the server has no way of knowing if the client is actually who they claim to be. If the client attempts to establish a secure connection and the server responds with "I can't give you a secure connection" then the client needs to assume there is a man in the middle attack going on and refuse to communicate with the server.
There is no way around it, security needs to be initiated on the client and the server cannot be allowed to refuse a secure connection.
HSTS is a partial solution for this problem (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)
Re:Encryption (Score:5, Informative)
A server cannot ask for encryption.
AFAIK, HTTP2 allows the server to encrypt even if the client didn't want to.
Unless the client establishes a secure connection in the first place, the server has no way of knowing if the client is actually who they claim to be. If the client attempts to establish a secure connection and the server responds with "I can't give you a secure connection" then the client needs to assume there is a man in the middle attack going on and refuse to communicate with the server.
If you're able to modify packets in transit (i.e. Man in the Middle), then you can also just decrypt with your key and re-encrypt with the client key. Without authentication, there's just nothing that's going to prevent a MitM attack. Despite that, being vulnerable to MitM is much better than being vulnerable to any sort of passive listening.
Re:Good point, except... (Score:5, Informative)
PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).
Varnish was never intended to support TLS, nor do the majority of Varnish users (myself included) want it to. The core issues being discussed have little to do with Varnish, aside from the fact that PHK has an excellent understanding of HTTP and high performance content delivery. Having written an HTTP proxy of my own to perform certain other tasks, I understand and largely agree with his sentiments.
That said, it should be noted that many people who need to support TLS connections already use separate software in front of Varnish for cases where high performance intermediate HTTP caching is desirable. This is really a separate topic from discussion of HTTP/2 and/or SPDY, but implementation of a SPDY to HTTP proxy could handle cases where an administrator wishes to run software that only speaks HTTP, albeit with the drawback that SPDY-specific features would be unavailable.
For many use cases, the ability to support 30,000 concurrent HTTP connections with a single VM outweighs the value proposition of encrypting the content in transit, especially for cases where the content in transit isn't remotely sensitive in nature. While "encryption doesn't add much overhead, Google said so" is a commonly parroted idea these days, if you take the opportunity to test various deployment scenarios you'll quickly find that assertion is false for many of those use cases.