[ameliaquining]

It's not correct to attribute all bugs to carelessness, and therefore assume that engineer conscientiousness is the only criterion affecting defect rates. Some software architectures, protocol designs, programming languages, etc., are less prone than others to certain kinds of implementation bugs, by leaving less room in the state space for them to hide undetected. Engineers of any skill level will produce far more defects if they write in assembly, than if they write the same code in a modern language with good static analysis and strong runtime-enforced guarantees. Likewise for other foundational decisions affecting how to write a program.

The post makes the case that HTTP/2 is systematically less vulnerable than HTTP/1 to the kinds of vulnerabilities it's talking about.

[mittensc]

> It's not correct to attribute all bugs to carelessness

Sure, just the bugs in the link.

Content-Length+Transfer-Encoding should be bad request.

RFC is also not respected: "Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a"

Content-Lenght: \r\n7 is also a bad request.

Just those mean whoever wrote the parser didn't even bother read the RFC...

No parsing failure checks either...

That kind of person will mess up HTTP/2 as well.

It's not a protocol issue if you can't even be bothered to read the spec.

> The post makes the case that HTTP/2 is systematically less vulnerable than HTTP/1 to the kinds of vulnerabilities it's talking about.

Fair enough, I disagree with that conclusion. I'm really curious what kind of bugs the engineers above would add with HTTP/2, will be fun.

[jsnell]

> Content-Length+Transfer-Encoding should be bad request.

Maybe it should be, but it isn't. In fact, all revisions of the HTTP/1.1 RFC have made it clear that if both headers are present, the receiver must treat it as the Content-Length header not being present. Not as an error.

RFC 2616 "If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored."

RFC 7230 "If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length"

RFC 9112 "... Transfer-Encoding is defined as overriding Content-Length, as opposed to them being mutually incompatible."

> RFC is also not respected: "Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a"

That's a spec mistake in the original RFC, corrected in later revisions. It would be an absurd requirement: if the input is chunked, the output must be chunked as well. If the sender is sending gzip and the receiver accepts it, what is gained from the proxy decompressing the stream only to immediately compress it?

> Content-Lenght: \r\n7 is also a bad request.

... I mean, yes, it would be a bad request. But the example in the article is "Content-Lenght: \r\n 7" which isn't invalid. It's a feature defined in RFC 2616 as folding. It was a bad idea and deprecated in later revisions, but that just means that a client should not send it. A server or proxy can either reject the message or undo the folding, they're just not allowed to pass them through unmodified.

[ameliaquining]

At least in the Cloudflare case, if you look at the postmortem (https://blog.cloudflare.com/resolving-a-request-smuggling-vu...) and the commit that fixed the bug (https://github.com/cloudflare/pingora/commit/fda3317ec822678...), it's significantly more complicated than "they didn't read the RFC", and a conclusion that a diligent engineer would never ever make this kind of mistake does not seem justified.

[adgjlsfhk1]

I think the main point is that these sorts of parsing mistakes shouldn't be so easily exploitable and the problem is that the length is non trivial to parse, so if you mess up the parsing of that it escalates the security of a ton of other bugs.