Hi, I'm the author - please let me know if you have any questions!
HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
61–70 of 116 posts
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#62Earlier quoted context omitted.
Out of the ecosystems I’m familiar with, Python application servers have terrible http2 support: neither gunicorn nor uwsgi supports it, and even new hotness like uvicorn is pretty far from it. I don’t think Ruby is doing much better? Correct me if I’m wrong.
But why would you need HTTP/2 perfect support in real world application server? They are never going to terminate the client traffic, they will speak with a load balancer which can speak HTTP/1.1 with them. Sure, if you are at webscale or even less you want everything on HTTP/2 for optimization sake. But in the rest of cases, even if you are in a solo project, you can easily enough put an nginx before it, or a cloud…
The whole point of this article is that proxies speaking HTTP2 with clients and HTTP1.1 with servers introduce new vulnerabilities. The author found such vulnerabilities in AWS ALB, several WAF solutions, F5 BigIP, and others.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#63Really 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."
As far as I'm aware, none of the techniques referenced in this paper work on Cloudflare as-is. Of course I probably missed a bunch of variations, so it's still worth them doing some internal checks.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#64I'm a bit confused how these attacks can be used.
Inconsistencies between HTTP/1.1 and HTTP/2 allow for these behaviours but you still need to inject these malicious prefixes in to a user's request flow, right?
Can you actually set the Content-Length header from a browser on a HTTP/2 request? And isn't the suffix just ignored by the final remote (or does this depend on HTTP/1.1 pipelining?)
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#65So 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…
I think the main problem is indeed missing HTTP2 support in backend servers. This is often just a case of people not being willing to upgrade for various reasons, even if the technology they are using would support HTTP2 in newer versions.
The problem is that HTTP/2 pretty much forces encryption. Most people don't want to deal with certificate management/rotation on every single microservice's application server.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#66I'm a bit confused how these attacks can be used. Inconsistencies between HTTP/1.1 and HTTP/2 allow for these behaviours but you still need to inject these malicious prefixes in to a user's request flow, right? Can you actually set the Content-Length header from a browser on a HTTP/2 request? And isn't the suffix just ignored by the final remote (or does this depend on HTTP/1.1 pipelining?)
Hi, I'm the author. This paper is building on techniques explained here: https://portswigger.net/research/http-desync-attacks-request...
This attack does not require a MITM - the attacker would use a tool like Burp Suite to issue the (technically RFC-violating) HTTP request. The prefix injection happens because front-end places the attacker's request and the victim's request on the same HTTP/1.1 connection to the back-end, as shown in this diagram: https://portswigger.net/cms/images/9c/c1/4c32-article-http2-...
> isn't the suffix just ignored by the final remote The back-end treats the suffix as the start of the next request, due to TCP buffering. The vast majority of servers have this kind of accidental pipelining support thanks to TCP.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#67Earlier quoted context omitted.
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…
From a server point of view there is very little difference between connection reuse and pipelining. The latter just means more data might already be in the input socket when the first request is handled - but it will not be used and either sit around in socket buffers or some TLS buffer. And i actually guess the person who mentioned pipelining just meant connection reuse.
I guess the difference is that the server is still free to return the "Connection: close" header on the first response and simply not read and/or process the other requests?
The client would then be expected to close the socket, possibly causing a TCP reset (if the server hadn't read all the data off the socket)
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#68Earlier quoted context omitted.
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…
From a server point of view there is very little difference between connection reuse and pipelining. The latter just means more data might already be in the input socket when the first request is handled - but it will not be used and either sit around in socket buffers or some TLS buffer. And i actually guess the person who mentioned pipelining just meant connection reuse.
"And I actually guess..."
Your guess is incorrect. I mean sending multiple requests over a single TCP connection. Usually 100 or more.
When performing information retrieval, e.g., fetching a series of pages from the same host, I do not want out of order responses. I want the responses returned in order. I want the HTTP headers, too, as record separators and so I can be sure all requests were filled.
This sort of pipelining is not useful for websites that want to source myriad resources into their pages from external sources to serve ads, perform tracking and all that commercially-oriented stuff that is necessary for companies like Google to survive. HTTP/2 is useful for commercially-oriented use of the web. Surveillance and ads. I'm not interested in using the web that way.
HTTP/1.1 pipelining is useful for informational retrieval, i.e., retrieving hundreds of resources from the same host without opening up hundreds of connections. That sort of bulk information retrieval is not compatible with online advertising and tracking. Thus, Google and other companies supporting HTTP/2 have no interest in it. It benefits users, not advertisers.
I fully expect some nasty comments from "tech" workers whenever I bring up this topic. I am speaking from a user persepctive, not a "developer" perspective.
In the early days of the web, opening up hundreds of connections at once would be poor etiquette (toward the server operator). Today, many so-called "engineers" do not know any other way. Not only do they do it to servers (e.g, asynchronous requests), they do it to clients, causing a user's browser to make hundreds of requests to different servers for a single web page. Looking at a Network panel in Developer Tools in a popular browser when accessing an "average" web page reveals the sheer insanity of so-called today's "web development". The other commenter clearly has never even used HTTP/1.1 pipelining, at least not consciously, and yet he wants to offer his opinion on it. Nice.
I use HTTP/1.1 pipelining every day. For example, I use it to retrieve bulk DNS data from DoH servers. The future of HTTP/2 is uncertain. HTTP/1.1 is not going away anytime soon.
I can test every website that is currently submitted to HN for pipelining support. I would bet the majority allow pipelining. If I wanted to retrieve a large number of pages from any of them, I could use pipelining to do it.
I get no benefits from HTTP/2 because I mainly use the web for non-commercial purposes. For that use, I do not use a popular browser. I do not wait for websites to "load" whilst they open dozens or even hundreds of connections to other servers. I retrieve HTML from the command line using netcat and haproxy. It's fast. I use a text-only browser to read HTML.
When using the web in the way I do, without seeing any ads, without all the automatically triggered requests to external servers, performance is not an issue. When using the web the way Google wants people to use it, chock full of ads, then performance is an issue and something like HTTP/2 makes sense. Thus, how one uses the web matters. One size does not fit all.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#69Earlier quoted context omitted.
I think the main problem is indeed missing HTTP2 support in backend servers. This is often just a case of people not being willing to upgrade for various reasons, even if the technology they are using would support HTTP2 in newer versions.
The problem is that HTTP/2 pretty much forces encryption. Most people don't want to deal with certificate management/rotation on every single microservice's application server.
If you're running microservices, won't you be running them on a platform?
If on Kubernetes, just install cert-manager. Or if using FaaS, your platform will already do TLS termination, no?
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#70Earlier quoted context omitted.
But why would you need HTTP/2 perfect support in real world application server? They are never going to terminate the client traffic, they will speak with a load balancer which can speak HTTP/1.1 with them. Sure, if you are at webscale or even less you want everything on HTTP/2 for optimization sake. But in the rest of cases, even if you are in a solo project, you can easily enough put an nginx before it, or a cloud…
The whole point of this article is that proxies speaking HTTP2 with clients and HTTP1.1 with servers introduce new vulnerabilities. The author found such vulnerabilities in AWS ALB, several WAF solutions, F5 BigIP, and others.
Yeah but serving traffic from an application server directly is probably even worse in plethora of other failure modes.
EDIT: and yes I understand that you should use http/2 on the LB and http/2 on the backend to get the best of both worlds.
EDIT2: anyway my opinion is that the general reaction to a security discovery like this one shouldn't be "let's stop using this tech immediately" but "let's get this patched ASAP"