Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

portswigger.net

Post reply on HN
Print view View original

31–40 of 116 posts

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#31

Post by 1vuio0pswjnm7 »

dagenix wrote: post #30
1vuio0pswjnm7 wrote: post #19

Earlier quoted context omitted.

"HTTP/2's binary format means you can't use classic general-purpose tools like netcat and openssl. HTTP/2's complexity means you can't easily implement your own client, so you'll need to use a library." IOW, HTTP/2 is not designed for users. It is designed for online advertisers and the companies that serve them. How do I know this. Because HTTP/1.1 pipelining still works great. I am using it on a separate task as I…

HTTP/1.1 pipelining is fundamentally flawed and largely unused. There isn't some conspiracy not to use it - many, many projects evaluated it and pretty much all came to that same conclusion.

I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of websites I encounter enable HTTP/1.1 pipelining. Therefore I use it.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#32

Post by pabs3 »

duskwuff wrote: post #21
jiggawatts wrote: post #7

I've been burnt one too many times by trying to "upgrade" to HTTP/2. It simply broke client certificate authentication and NTLM authentication, leaving only cookie-based authentication fully functional. Can you guess which two of the three popular authentication mechanisms Google doesn't use? It's not a protocol designed to advance the Internet, it's a protocol designed by Google to shave 1% off their network bill.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use? Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable ) on any other public web site, either. TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many brows…

> There's no way for an average user to transfer a certificate from one device to another.

Wouldn't you just enrol a new certificate from the new device?

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#33

Post by pabs3 »

duskwuff wrote: post #21
jiggawatts wrote: post #7

I've been burnt one too many times by trying to "upgrade" to HTTP/2. It simply broke client certificate authentication and NTLM authentication, leaving only cookie-based authentication fully functional. Can you guess which two of the three popular authentication mechanisms Google doesn't use? It's not a protocol designed to advance the Internet, it's a protocol designed by Google to shave 1% off their network bill.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use? Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable ) on any other public web site, either. TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many brows…

> There's no way to log out without closing the browser.

Well, with TLS client certs, each request is essentially similar to a new login, request, logout, so "logout" doesn't really make sense, unless you want to it to mean "stop using the cert temporarily"? Perhaps the UX for certs should be more like "this site wants you to login", you press login in the browser UI, then all future requests are signed with your cert, until you click logout in the browser UI and then they aren't signed any more.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#34

Post by pabs3 »

duskwuff wrote: post #21
jiggawatts wrote: post #7

I've been burnt one too many times by trying to "upgrade" to HTTP/2. It simply broke client certificate authentication and NTLM authentication, leaving only cookie-based authentication fully functional. Can you guess which two of the three popular authentication mechanisms Google doesn't use? It's not a protocol designed to advance the Internet, it's a protocol designed by Google to shave 1% off their network bill.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use? Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable ) on any other public web site, either. TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many brows…

> TLS client certificates have always been a UX nightmare.

Indeed, it is very sad; they could be a great auth standard if only the client UX was acceptable.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#35

Post by dagenix »

The title seem very much anti-HTTP/2. However, unless I missed something huge, the vast majority, if not all, of the issues found relate to how hard it is to handle HTTP/1. And it seems kinda odd to blame HTTP/2 for HTTP/1 being difficult to implement.

I'm certainly not trying to downplay the seriousness of these issues. But it seems like a equally (it not more) valid title might be something like "HTTP/1: Continues to rear its ugly head" or something like that.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#36

Post by duskwuff »

pabs3 wrote: post #32
duskwuff wrote: post #21

Earlier quoted context omitted.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use? Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable ) on any other public web site, either. TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many brows…

> There's no way for an average user to transfer a certificate from one device to another. Wouldn't you just enrol a new certificate from the new device?

How would you do that? The old device doesn't know anything about the new certificate, and the new device can't prove that it's the successor to the old device.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#37

Post by comex »

chrismorgan wrote: post #29
carey wrote: post #2

Given the long history of request parsing vulnerabilities in HTTP/1.1 servers and proxies, is HTTP/2 actually worse, or have most of the HTTP/1.1 bugs just been fixed already?

These vulnerabilities are all from badly-written HTTP/2 → HTTP/1.1 translations. Most of them come from simple carelessness, rookie errors that should never have been made , dumping untrusted bytes from an HTTP/2 value into the HTTP/1.1 byte stream. This is security 101, straightforward injection attacks with absolutely nothing HTTP-specific in it. Some of them are a little more complex, requiring actual HTTP/2 and H…

I'd agree that HTTP/1 deserves a significant portion of the blame.

On the other hand, one maxim I've learned from my time bug hunting is that nobody ever validates strings in binary protocols. As such, I'm utterly unsurprised there are so many implementations with these kinds of bugs, and I'd say they could have been predicted in advance.

In fact… let's see… yep, they were predicted. Some of them, at least. In the HTTP/2 RFC, under Security Considerations, 10.3 'Intermediary Encapsulation Attacks' describes one of the attack classes from the blog post, the one involving stuffing newlines into header names.

Does that mean something could have been done about it? Perhaps not. The ideal solution would be to somehow design the HTTP/2 protocol itself to be resistant to misimplementation, but that seems pretty much impossible. The spec already bans colons and newlines in header names, but there's no way to be sure implementations won't allow them anyway, short of actually making them a delimiter like HTTP/1 did – in other words, reverting to a text-based protocol. But a text-based protocol would come with its own share of misimplementation risks, the same ones that HTTP/1 has.

On the other hand, perhaps the bug classes could have been mitigated if someone designed test cases to trigger them, and either included them in conformance tests (apparently there was an official HTTP/2 test suite [2] though it doesn't seem to have been very popular), or set up some kind of bot to try them on the entire web. In principle you could blame the authors of HTTP/2 collectively for the fact that nobody did this. But I admit that's pretty handwavey.

[1] https://datatracker.ietf.org/doc/html/rfc7540#section-10.3

[2] https://github.com/http2/http2-test

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#38

Post by dagenix »

1vuio0pswjnm7 wrote: post #31
dagenix wrote: post #30

Earlier quoted context omitted.

HTTP/1.1 pipelining is fundamentally flawed and largely unused. There isn't some conspiracy not to use it - many, many projects evaluated it and pretty much all came to that same conclusion.

I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of website…

Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup.

https://en.wikipedia.org/wiki/HTTP_pipelining: says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support.

https://forum.nginx.org/read.php?2,269248,269249#msg-269249: Some person says that Nginx doesn't support pipelining. Other people agree. I can't find anything to contradict that.

https://serverfault.com/questions/266184/does-apache-webserv...: Someone says that Apache doesn't support pipelining. Again, I can't find anything to contradict that.

https://stackoverflow.com/questions/17299489/iis-and-http-pi...: This person says IIS doesn't support pipelining. Against, I can't find contradictory evidence.

Twisted used to support pipelining, but removed it: https://twistedmatrix.com/trac/ticket/8320

So, who exactly supports HTTP/1.1 pipelining?

It is true that if you fire multiple requests off to an HTTP/1.1 host without waiting for a response, you'll probably get responses back. The thing is that most hosts will process those requests one at a time. This is not pipelining - this is just processing requests one at a time as they come in. So, you're saving the latency required to get the request to the server - but not getting any benefit from parallel processing since the servers process the requests serially. With HTTP/2, however, at least some servers will actually process those requests in parallel - potentially with better performance.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#39

Post by tptacek »

chrismorgan wrote: post #29
carey wrote: post #2

Given the long history of request parsing vulnerabilities in HTTP/1.1 servers and proxies, is HTTP/2 actually worse, or have most of the HTTP/1.1 bugs just been fixed already?

These vulnerabilities are all from badly-written HTTP/2 → HTTP/1.1 translations. Most of them come from simple carelessness, rookie errors that should never have been made , dumping untrusted bytes from an HTTP/2 value into the HTTP/1.1 byte stream. This is security 101, straightforward injection attacks with absolutely nothing HTTP-specific in it. Some of them are a little more complex, requiring actual HTTP/2 and H…

It's tough to say that something is a "rookie error" when basically every serious professional team makes the same mistake. This broke apparently broke every AWS ALB, for instance.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#40

Post by dagenix »

dagenix wrote: post #38
1vuio0pswjnm7 wrote: post #31

Earlier quoted context omitted.

I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of website…

Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup. https://en.wikipedia.org/wiki/HTTP_pipelining : says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support. https://forum.nginx.org/read.php?2,269248,269249#msg-269249 : Some person says that Ngin…

This isn't a conspiracy - the problem with HTTP/1.1 pipelining is that responses have to go out in the same order as the requests that generated them. So, if a slow request comes in that generates a small amount of data, followed by 10 fast requests that generate a lot of data, the server has to hold all those big, fast responses in memory until the slow one finishes. That's bad for utilization - and it makes it easier to DOS a server. With HTTP/2, the server can respond immediately to whichever request finishes first - which is much better for utilization of server resources.
Post reply on HN