PHK: HTTP 2.0 Should Be Scrapped

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 ?"

Comments

Encryption

[neokushan]

I hope that whatever HTTP2.0 ends up being enforces encryption by default.

Re:Encryption

[Anonymous Coward]

No, you really don't. Encryption is good for Facebook, but enforcing it for your Internet-of-Everything lightbulb or temperature probe in the basement gains nothing other than more complex bugs and lower battery life.

Re:Encryption

[Anonymous Coward]

Nice try NSA.

Re:Encryption

[jmv]

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

[abhi_beckert]

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

[jmv]

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:Encryption

[AuMatar]

It doesn't need to be perfect. If cracking it still takes some time, it lowers their resources. And it can still be unbreakable for attackers with fewer resources at their disposal.

Re:Encryption

[jmv]

Nothing is NSA-proof, therefore we should just scrap TLS and transmit everything in plaintext, right? The whole point here is not to make the system undefeatable, just to increase the cost of breaking it, just like your door lock isn't perfect, but still useful. If HTTP was always encrypted, even with no authentication, it would require the NSA to man-in-the-middle every single connection if it wants to keep its pervasive monitoring. This would not only make the cost skyrocket, but also make it trivial to detect.

Re:Encryption

[gweihir]

Unfortunately, breaking the crypto directly is _not_ what they are going to do. Protocol flaws usually allow very low cost attacks, it just takes some brain-power to figure them out. The NSA has a lot of that available.

Re:Encryption

[swillden]

In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.

SPDY's security component is TLS. SPDY is essentially just some minor restrictions (not changes) in the TLS negotiation protocol, plus a sophisticated HTTP acceleration protocol tunneled inside. So this really isn't a "first attempt", by any means. Not to mention the fact that Google has been using SPDY extensively for years now and has a great deal of real-world experience with it. Your argument might hold water when applied to QUIC, but not so much to SPDY.

It really helps to read the thread and get a sense of what the actual dispute is about. In a nutshell, Kamp is bothered less that HTTP/2 is complex than that it doesn't achieve enough. In particular, it doesn't address problems that HTTP/1.1 has with being used as a large file (multi-GB) transfer protocol, and it doesn't eliminate cookies. Not many committee members seem to agree that these are important problems for HTTP/2, though most do agree that it would be nice some day to address those issues, in some standard.

What many do agree on is that there is some dangerous complexity in one part of the proposal, a header compression algorithm called HPACK. The reason for using HPACK is the CRIME attack, which exploits Gzip compression of headers to deduce cookies and other sensitive header values. It does this even though the compressed data is encrypted. HPACK is designed to be resistant to this sort of attack, but it's complex. Several committee members are arguing that it would be reasonable to proceed without header compression at all, thus greatly simplifying the proposal. Others are arguing that they can specify HPACK, but make header compression negotiable and allow clients and servers to choose to use nothing rather than HPACK, if they prefer (or something better when it comes along).

Bottom line: What we have here is one committee member who has been annoyed that his wishes to deeply rethink HTTP have been ignored. He is therefore latching onto a real issue that the rest of the committee is grappling with and using it to argue that they should just throw the whole thing out and get to work on what he wanted to do. And he made his arguments with enough flair and eloquence to get attention beyond the committee. All in all, just normal standards committee politics which has (abnormally) escaped the committee mailing list and made it to the front page of /.

His previous comments are much better

[Anonymous Coward]

Why HTTP/2.0 does not seem interesting

Convincing

[gweihir]

There is also the other thing that there is no urgent need to replace HTTP/1.1, despite of what people claim. Sure, it has problems, but the applications it does not support so well are things that there is not urgent need for, hence there is no urgent need for a protocol replacement. It would be far better to carefully consider what to put into the successor and what not. And KISS should the the overriding concern, anything else causes a lot more problems and wastes a lot more resources than having the successor a few years later.

Moving goal posts

[abhi_beckert]

I don't think HTTP has any problems with security. All the real world problems with HTTP security are caused by:

  * dismally slow roll out of dnssec. It should have been finished years ago, but it has barely even started.
  * the high price of acquiring an SSL certificate (it's just bits!).
  * slow rollout of IPv6 (SSL certificates generally require a unique IP and we don't have enough to give every domain name a unique IP).
  * arguments in the industry about how to revoke a compromised SSL certificate, which has lead to revocation being almost useless.
  * SSL doesn't really work when there are thousands of certificate authorities, so some changes are needed to cope with the current situation (eg: dsnssec could be used to prevent two certificate authorities from signing the same domain name)

Death by Committee

[bill_mcgonigle]

HTTP/1.1 is roughly seventeen years old now - technically HTTP/1.0 came out seven years before that, but in terms of mass adoption, NSFNet fizzled in '94 and then people really started to pay attention to the web - I had my first webpage about six months before that (at College) and there were maybe a dozen in the whole school who had heard of it previously. Argue for seven years if you'd like, but I'll say that HTTP/1.0 got seriously revised after three years of significant broad usage. SSLv3, still considered almost usable today, was released the year before. TLSv1.2, considered good, has been a standard for over five years and still it's poorly supported though now critically necessary for some security surfaces.

After this burst of innovation, somebody dreamt up the W3C and we got various levels of baroque standards, all while everybody else solved the same problems over and over again. IETF used to be pretty efficient, but it seems like they're at the same point now.

I won't argue for SPDY becoming HTTP/2.0 but I will admire it as an effort to freaking do something. Some guys at Google said, "look, screw you guys, we're going to try to fix this mess," and they did something. While imperfect, they still did enough that the HTTP/2.0 committee looked at it and said (paraphrasing), "hrm, since we haven't done anything useful for 15 years, let's take SPDY and tweak it and call it a day's work well done."

The part Google got most right was the "screw you guys" part - central-planning the web is not working.. I'm not positive what the right organization structure looks like, but it's not W3C and IETF. We need to figure out what went right back in the mid 90's and do that again, but now with more experience under our belts. This talk of "one protocol to rule them all for 20 years" is undeniably a toxic approach. HTTP/1. 1 should have been deprecated by 2005 and we should be on to the third iteration beyond it by now. Yeah, more core stuff for the devs to do - used to be we had people who could start a company and write a whole new web browser in a year - half the time it takes to change the color of tabs these days.

And don't start with this "but this old browser on ... " crap either - we rapidly iterated before and can do it again. Are there people who fear change? Sure - and nobody is going to stop HTTP/1.1 from working 50 years from now, but by golly nobody should want to use it by then either.

Re:Good point, except...

[MassacrE]

It is a technical discussion. Unless you are prepared to provide feedback on how to make a more private/anonymous protocol which can serve as a drop-in replacement for HTTP 1.1, "normal users" will just serve as background noise.

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).

Re:Good point, except...

[philip.paradis]

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.

Tunnelling

[msobkow]

Maybe if we weren't trying to tunnel every god damned protocol and transport known to mankind through HTTP it wouldn't be such a massive problem to re-engineer and fix.

Seriously: The idea of TCP was to have multiple protocol ports, not to tunnel everything over :80.

Re:Tunnelling

[Aethedor]

Yeah, tell that to the firewall administrator who thinks that opening an extra port is far more insecure than to tunnel that extra connection via HTTP. The IT world is defined by a mass amount of incompetent administrators and developers.