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

81–90 of 116 posts

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

#81

Post by [deleted] »

pabs3 wrote: post #33
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 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 cer…

[deleted]

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

#82

Post by londons_explore »

phicoh wrote: post #76
londons_explore wrote: post #65

Earlier quoted context omitted.

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.

Why does HTTP/2 force encryption? The HTTP/2 RFC (RFC 7540) also defines how to run HTTP/2 over plaintext. Terminating HTTP/2 over TLS on a web frontend and then HTTP/2 over plaintext to the application servers sounds like a viable model.

In practice HTTP/2 forces encryption. For example Amazons ALB docs say "Considerations for the HTTP/2 protocol version: The only supported listener protocol is HTTPS." [1]

[1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...

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

#83

Post by londons_explore »

orra wrote: post #69
londons_explore wrote: post #65

Earlier quoted context omitted.

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?

On kubernetes, cert-manager might get certificates for you, but you'll still need to make sure the application correctly reloads those certs (many application frameworks have no way to reload a certificate at runtime).

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

#84

Post by simiones »

orra wrote: post #69
londons_explore wrote: post #65

Earlier quoted context omitted.

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?

That assumes your application can connect to the internet and can be accessed from the internet. There is a vast array of offline-only kubernetes clusters.

You can still of course use self-signed certificates (or setting up your own "CA"), but you'll hit other problems related to runtime certificate reloads and so on. It's still a lot of work to enable SSL for fully offline services.

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

#85

Post by simiones »

1vuio0pswjnm7 wrote: post #19
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.

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

Note that in the quote above "use" refers to security researchers trying to send malformed traffic.

The only usability difference between HTTP2 and HTTP1(.1) is that it's easier to write a broken implementation of a quarter of HTTP1 and still do some useful things with it.

A full, production-grade HTTP1.1 client or server is more or less as complex as an HTTP2 client or server. HTTP2 is actually easier to implement at the base level, since it's much easier to work with binary protocol formats than with the horrible string encoding of HTTP1. HTTP2 does add a lot of complexity with the stream multiplexing features afterwards - more or less enough as to cover the endless headache of deciphering HTTP 1.1 requests and arcane connection headers.

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

#86

Post by simiones »

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 would bet that a lot of these are not rookie errors, they are more akin to Spectre or Meltdown: inherently unsafe code that was considered a valuable risk for performance.

In general, when writing a high performance middle box, you want to touch the data as little as possible: ideally, the CPU wouldn't even see most of the bytes in the message, they would just be DMA'd from the external NIC to the internal NIC. This is probably not doable for HTTP2->HTTP1, but the general principle applies. In high-performance code, you don't want to go matching strings any more than you think is strictly necessary (e.g. matching the host or path to know where to actually send the packet).

Which is not to say that it wasn't a mistake to assume you can get away with this trade-off. But it's not a rookie error.

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

#87

Post by JulianWasTaken »

oefrha wrote: post #53
mhitza wrote: post #20

So 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…

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.

The building blocks are there. In Python we have the wonderful (and wonderfully sans-io) h2[1] by Cory Benfield. E.g. here's a Twisted h2-using implementation: https://python-hyper.org/projects/hyper-h2/en/stable/twisted...

h2: https://github.com/python-hyper/h2

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

#88

Post by gnfargbl »

@albinowax_, can you say anything more about how widely you have investigated the prevalence of the "H2.X via Request Splitting" vulnerability?

Although all of your attack vectors are fascinating, this seems to be the one which is particularly terrifying. It seems like one single request can basically mess up user authentication across an entire website, and for every active user, until the server becomes resynchronized somehow. If I were running a large public-facing site or application, checking for this vulnerability would be my #1 priority this morning.

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

#89

Post by albinowax_ »

gnfargbl wrote: post #88

@albinowax_, can you say anything more about how widely you have investigated the prevalence of the "H2.X via Request Splitting" vulnerability? Although all of your attack vectors are fascinating, this seems to be the one which is particularly terrifying. It seems like one single request can basically mess up user authentication across an entire website, and for every active user, until the server becomes resynchroni…

Good question! So, my understanding is that the majority of servers that are vulnerable to regular cross-user HTTP Request Smuggling (IE, reuse connections to the back-end server) are exposed to this terrifying response queue poisoning attack. This applies to all desync types CL.TE, TE.CL, H2.CL, etc. The reason I discovered this in the H2.X case, is because it's particularly easy to trigger response queue poisoning by accident in this scenario.

That said, I haven't actually tested this on very many live servers, for obvious reasons!

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

#90

Post by phicoh »

josefx wrote: post #80
phicoh wrote: post #73

Earlier quoted context omitted.

Yes, it is weird that a broken protocol translator results in blame for the newer protocol. As far as I can tell, the article doesn't attack HTTP2, that seems work fine. The article clearly demonstrates the problems of HTTP1. But the real problem is sloppy HTTP2 forntends that generate broken HTTP1.

> Yes, it is weird that a broken protocol translator results in blame for the newer protocol. From a look at the HTTP/2 spec. this protocol translation is an expected use case and explicitly results in several restrictions on the contents of HTTP/2 headers. So going by the HTTP/2 spec. at least some of those headers should have been rejected by a conformant front end and never made it into HTTP/1.

So how is a collection of broken translators the fault of HTTP/2? The title says 'The Sequel is Always Worse'. It is not HTTP/2 that is bad. It is translation to the, from a security point of view, problematic HTTP/1 that is the problem.
Post reply on HN