HTTP/1.1 must die: the desync endgame • Hacker News Board

Re: HTTP/1.1 must die: the desync endgame

#21

Post by Bender » Fri, Aug 15, 2025, 8:14 PM UTC

spenczar5 wrote: post #3

I dont know, arguing that http/2 is safer overall is a... bold claim. It is sufficiently complex that there is no standard implementation in the Python standard library, and even third party library support is all over the place. requests doesn't support it; httpx has experimental, partial, pre-1.0 support. Python http/2 servers are virtually unavailable at all . And it's not just Python - I remember battling memory…

Speaking of http/2 [1] - August 14, 2025

The underlying vulnerability, tracked as CVE-2025-8671, has been found to impact projects and organizations such as AMPHP, Apache Tomcat, the Eclipse Foundation, F5, Fastly, gRPC, Mozilla, Netty, Suse Linux, Varnish Software, Wind River, and Zephyr Project. Firefox is not affected.

[1] - https://www.securityweek.com/madeyoureset-http2-vulnerabilit...

Re: HTTP/1.1 must die: the desync endgame

#22

Post by mittensc » Fri, Aug 15, 2025, 8:18 PM UTC

ameliaquining wrote: post #16

mittensc wrote: post #12

The article is a nice read on request smuggling. It over-reaches with argument about disallowing http/1.1. Parsers should be better. Moving to another protocol won't solve the issue. It will be written by the same careless engineers. So same companies will have the same issues or worse... We just lose readability/debuggability/accesibility.

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

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

Re: HTTP/1.1 must die: the desync endgame

#23

Post by adgjlsfhk1 » Sat, Aug 16, 2025, 1:34 AM UTC

mittensc wrote: post #22

ameliaquining wrote: post #16

Earlier quoted context omitted.

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

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

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.

Re: HTTP/1.1 must die: the desync endgame

#24

Post by ameliaquining » Sat, Aug 16, 2025, 1:25 PM UTC

mittensc wrote: post #22

ameliaquining wrote: post #16

Earlier quoted context omitted.

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

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

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.

Re: HTTP/1.1 must die: the desync endgame

#25

Post by jsnell » Sat, Aug 16, 2025, 1:44 PM UTC

mittensc wrote: post #22

ameliaquining wrote: post #16

Earlier quoted context omitted.

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

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

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

Re: HTTP/1.1 must die: the desync endgame

#26

Post by yencabulator » Mon, Aug 18, 2025, 7:53 PM UTC

Bender wrote: post #21

spenczar5 wrote: post #3

I dont know, arguing that http/2 is safer overall is a... bold claim. It is sufficiently complex that there is no standard implementation in the Python standard library, and even third party library support is all over the place. requests doesn't support it; httpx has experimental, partial, pre-1.0 support. Python http/2 servers are virtually unavailable at all . And it's not just Python - I remember battling memory…

Speaking of http/2 [1] - August 14, 2025 The underlying vulnerability, tracked as CVE-2025-8671, has been found to impact projects and organizations such as AMPHP, Apache Tomcat, the Eclipse Foundation, F5, Fastly, gRPC, Mozilla, Netty, Suse Linux, Varnish Software, Wind River, and Zephyr Project. Firefox is not affected. [1] - https://www.securityweek.com/madeyoureset-http2-vulnerabilit...

Protocol smuggling is a lot more severe than DoS.