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

41–50 of 116 posts

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

#41

Post by stkdump »

dagenix wrote: post #35

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…

I guess this is more in line with the narrative that older protocols that people are more familiar with are somehow always better. That there is a hidden evil agenda for introducing something new. Or at least that we all need to pay a price for the sole benefit of a tech giant. It is a convenient narrative, which could be true, but it feels too easy a conclusion. Which makes it a good clickbait.

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

#43

Post by tene »

tptacek wrote: post #39
chrismorgan wrote: post #29

Earlier quoted context omitted.

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.

An error that's extremely common among people doing their first work on a specific domain seems like a good fit for "rookie error".

It's easy to believe most professional teams make that mistake at some point. I'd hope that it's far more rare to make that mistake twice.

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

#45

Post by tene »

duskwuff wrote: post #36
pabs3 wrote: post #32

Earlier quoted context omitted.

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

You use some other form of authentication, like a password, or clicking an emailed link, or clicking an "approve" button on the old device if available, or anything else that makes sense for your relationship with your users.

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

#46

Post by duskwuff »

tene wrote: post #45
duskwuff wrote: post #36

Earlier quoted context omitted.

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.

You use some other form of authentication, like a password, or clicking an emailed link, or clicking an "approve" button on the old device if available, or anything else that makes sense for your relationship with your users.

And how does the server remember that you've provided one of those other forms of authentication? Recall that the original goal was to be an alternative to cookies...

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

#47

Post by atoav »

comex wrote: post #37
chrismorgan wrote: post #29

Earlier quoted context omitted.

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

> On the other hand, one maxim I've learned from my time bug hunting is that nobody ever validates strings in binary protocols.

I wonder how much this has to do with the way strings need to be handled in the programming languages these protocols are implemented in. If dealing with strings is something that seems to be even more of a danger (if done incorrectly) you might just not do it.

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

#48

Post by pabs3 »

duskwuff wrote: post #36
pabs3 wrote: post #32

Earlier quoted context omitted.

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

Same as how you verify the keys of another person, manually transferring the hex digits of the fingerprint, or something more user-friendly like QR codes or audio or BT data transmission.

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

#49

Post by tptacek »

tene wrote: post #43
tptacek wrote: post #39

Earlier quoted context omitted.

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.

An error that's extremely common among people doing their first work on a specific domain seems like a good fit for "rookie error". It's easy to believe most professional teams make that mistake at some point. I'd hope that it's far more rare to make that mistake twice.

No, that doesn't make sense. The errors that trip seasoned pros up are very likely to trip rookies up as well. Words mean things; rookie mistakes the mistakes that don't trip up the pros.

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

#50

Post by ikiris »

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…

this kind of terrible implementation is a lot of why encrypted quic exists.
Post reply on HN