4 ms·
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 ha
by dagenix 5y ago
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.
- stkdump 5y agoI 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.
- dathinab 5y ago> It is a convenient narrative It's also not he narrative the content of the article purses ;-)
- albinowax_ 5y agoHi, I'm the author. This paper is about HTTP/2, and the dangerous things that happen behind the scenes with HTTP/1 when people enable it. It's arguing that enabling HTTP/2 on your front-end makes your security worse if it's downgrading behind the scenes. This is a deliberately cheeky title, selected as a presentation title, rather than being aimed at social media where many people will read the title but not the contents. For HN I'd go with something dry like "HTTP/2-exclusive attack vectors".
- jpambrun 5y agoMy employer's mandatory proxy downgrades all HTTP/2, presumably so they can better inspect traffic. This results in a bad/slow experience on many sites. I wish HTTP/2 would not have downgrade at all so they would have to deal with it..
- phicoh 5y agoYes, 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.
- josefx 5y ago> 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.
- phicoh 5y agoSo 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.
- josefx 5y ago> It is translation to the, from a security point of view, problematic HTTP/1 that is the problem. Parts of the HTTP/2 spec. specify what malformed headers look like, so this bug is almost entirely in the code not validating those HTTP/2 headers. This also isn't something that a few high school dropouts got wrong on their side projects, several major services got it wrong. Given that the spec. made at least some attempts to warn its implementers maybe future standards need a security section titled "Important: Why ignoring security advisory in standards is a bad idea".
- rini17 5y agoMajority of the cases were requests that HTTP/2 clearly specified as malformed but they were not treated as such. It's reasonable to expect there will be other such implementation vulns that won't stem from HTTP/1 historical baggage - that is just where the author was looking today. So I'm fine with the "HTTP/2 is worse in its own" presumption because it's harder to implement. Then, the \r\n in headers can easily trip an application that was naively ported to http/2 supporting network library. That's too pretty ripe for blame shifting :)
- twic 5y agoMore than that, they relate to proxies. This sentence seems the crux to me: > If you're coding an HTTP/2 server, especially one that supports downgrading, enforce the charset limitations present in HTTP/1 - reject requests that contain newlines in headers, colons in header names, spaces in the request method, etc.
- ObscureScience 5y agoWhat's wrong with it? It seems reasonable to protect yourself from header-injections allowed by a downgrade? Am I misunderstanding?
- twic 5y agoI don't think there's anything wrong with it, it's great advice!
- tyingq 5y agoI imagine it also relates to things that really "proxies", but not normally thought of as such. Like PHP-FPM, wsgi, etc. Those are also doing protocol and header translation, and are very ubiquitous.