Burying the lede...
Unfortunately, at the time of this whitepaper being published - 86 days after Apache was notified of the vulnerability - 2.4.49 not yet come out, so although there's a patch on master, this is effectively a zero-day.
HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
11–20 of 116 posts
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#12I'm not a security person at all. Is there a quick explanation for how these attacks allow the attacker to mess with other clients' requests? I'm also confused at their usage of the word "prefix". Did they mean "suffix"? Or does "prefix" have a specific meaning in this case?
The next client's request gets sent after your request. If you get frontend and backend servers to desync, the backend gets to your first request, responds, and the response is sent to you; then the backend gets your second request + the next client's request, responds, and the response is sent to that next client.
This means you are making other clients get responses for their request prefixed by your smuggled second request.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#13I'm not a security person at all. Is there a quick explanation for how these attacks allow the attacker to mess with other clients' requests? I'm also confused at their usage of the word "prefix". Did they mean "suffix"? Or does "prefix" have a specific meaning in this case?
[deleted]
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#14I'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.
I always considere NTLM and Kerberos to be very similar, so I am surprised to hear that NTLM is broken.
Kerberos and HTTP/2 work just fine together.
What in particular is broken with NTLM?
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#15Burying the lede... Unfortunately, at the time of this whitepaper being published - 86 days after Apache was notified of the vulnerability - 2.4.49 not yet come out, so although there's a patch on master, this is effectively a zero-day.
I'm not seeing anything about this in nginx changelogs (or matching CVE's) either. Disabling http2 for now.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#16Really good explanations here. As a Cloudflare Enterprise customer I've opened a case with them to see if any of these vulnerabilities apply to their WAF. I was a bit surprised to see the article mention that Imperva's WAF was vulnerable.
edit: Cloudflare has responded that "[they] are asking your question internally."
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#17It seems most of the vulnerabilities here (at least, the first several that I read in the article) come at a point where an HTTP/2 request is transformed into an HTTP 1.1 request. So the insecurity seems to come at the point where a translation occurs and there is redundant information that can be handled in several ways, meaning that there's lots of room for bugs.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#18I'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.
I always considere NTLM and Kerberos to be very similar, so I am surprised to hear that NTLM is broken. Kerberos and HTTP/2 work just fine together. What in particular is broken with NTLM?
NTLM
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#19I'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.
"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 type this (I use it outside the browser).
It just doesn't work well for companies that profit from online advertising as a "business model", the so-called "ecosystem" of actors seeking to capture "eyeballs" and Hoover up data about users.
That includes people who design whiz-bang websites making dozens to hundreds of "automatic" requests not initiated by the user, many for arguably unnecessary external resources (or for telemetry), to gather data on the user and/or to serve her with ads.
The type of websites that drive HN readers nuts. That is not a problem with HTTP/1.1, that's a problem with the effects of online advertising, surveillance and greed run amok.
It also includes popular browsers supported by advertising. HTTP does not exist exclusively for a handful of corporate-sponsored browsers. It exists for all present and future clients that users wish to use to retreive information from the web.
HTTP/2 is biased against users in favour of a web that exists only for online advertising (so it can keep filling Google's pockets with cash). It is a protocol that is so complex that users, not to mention the author of this blog post, "cannot easily implement clients for it."
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#20So I was scratching my head for a good couple of minutes trying to figure out how this works, being familiar only with HTTP Response Splitting/HTTP Cache Poisoning.
So it seemed that somewhere along the years while I haven't been paying any attention to websec, it became a common practice to send requests from different clients through the same TLS connection. And due to the non conforming way HTTP 2/1.1 interop was implemented by these webservers/load balancers request boundaries were not delimited correctly, making it possible to inject requests on behalf of followup clients.
Fine I get the issue. Sounds like another "good enough" optimization that backfired.
What is the solution aside from playing the patching wack-a-mole game? Should maybe a HTTP2.1 protocol work without a strict TLS requirement so that protocol downgrades aren't necessary to squeeze out extra performance (unless I misunderstand why the HTTP2/HTTP1.1 bridge was in place). Or is the problem that some application servers still don't support HTTP2 out of the box?