Hacker News Reader

Comment by notriddle | Hacker News Reader

Not really. HTTP/1.1 already has enough complexity in it that most people can’t implement it securely (a legitimately simple protocol doesn’t have desync bugs).

https://portswigger.net/research/http-desync-attacks-request...

View on HN

Sure. Now imagine the edge cases and security flaws we will be discovering in HTTP 2 for the next decades. Fun.

Actually, a lot less. HTTP/2 frames are done as a binary protocol with fixed offsets, and instead of having three different transfer modes (chunked, keep-alive, and one-shot), HTTP/2 has only its version of chunked.

The best way to exploit an HTTP/2 server is to exploit the HTTP/1.1 server behind it [1].

[1]: https://portswigger.net/research/http2

> The best way to exploit an HTTP/2 server is to exploit the HTTP/1.1 server behind it [1].

The exploit mentioned is the http/2 front end getting confused by the amount of responses it gets because it never checked how many http/1.1 messages it was forwarding, it just assumed that the http/1.1 headers where matching the http/2 headers. Now in defense of http/2 this was completely expected, called out in the spec. as requiring validation in case of tunneling and ignored by every implementation.

Given that attack only applies to servers, and only when you have proxies in front of your servers, i don't think it disputes the claim that writing a minimal http client is quite simple.

You can implement a server without all those tricky features. Proxies are hard and a design wart if you use them.

Quoting your link it describes this politely, "By itself, this is harmless. However, modern websites are composed of chains of systems, all talking over HTTP. This multi-tiered architecture takes HTTP requests from multiple different users and routes them over a single TCP/TLS connection [...]"

I'd say it has enough naïveté to be susceptible to desync attacks.

Lax whitespace rules, lax repeating header rules, no advanced integrity checks like checksums, etc. I see these as signs of simplicity.

I think you're arguing for HTTP/1.2 instead

Why would you need checksums? There is already checksumming and error correction going on in the lower layers (TCP, Ethernet, ...).

If you have a content-length header, and a checksum after the declared number of bytes, it becomes way harder to desync a request: prepended data would change the checksum, and an altered length header would make the parser miss the checksum in the stream.

Lower layer checksums will tell you the data made it across the wire correctly but have no idea if that data was correct in the context of the application layer. Keep in mind HTTP isn't only used between web browsers and servers. A client might use a HMAC to verify the content wasn't MITMed. Lower layer packet checksums won't do that and TLS won't necessarily prevent it either. Even when MITM isn't an issue HTTP can be proxied so a header checksum could verify a proxy didn't do something wrong.

TLS will prevent it in any realistic scenario.

If you have a shared secret to support doing an hmac then you can certainly set up tls correctly.

TLS only cares about the security of the socket. It doesn't know anything about the content flowing through the socket. Additionally the TLS connection may not even be between the server and client but a proxy between the server and client, client and server, or both server and client. While TCP and TLS can get a message over the Internet correctly and securely they can't make any guarantees about the contextual validity of that message.

TLS does not obviate application layer checks it can only compliment them.

> TLS only cares about the security of the socket. It doesn't know anything about the content flowing through the socket.

Not sure what that means precisely, but if you're stretching definitions that far, the same is probably also true of your application checksums/hmacs

> Additionally the TLS connection may not even be between the server and client but a proxy between the server and client, client and server, or both server and client.

So its the same as your hmac check. That can also be processed at any layer.

> While TCP and TLS can get a message over the Internet correctly and securely they can't make any guarantees about the contextual validity of that message.

Can anything at the http protocol layer provide that?

I cannot envision a problem that a checksum in the HTTP protocol would fix that TLS wouldn't also fix.

You have to ask yourself "How would this get corrupted"? If the concern is that the data ends up somehow mangled from an external source like a bad router or a lose cable, then the data simply won't decrypt correctly and you'll end up with garbage.

So that leaves you with an application bug. However, an app is just as likely to add a checksum for an invalid body as they are to add one for a valid body.

So, the only fault I could see this fixing is an application which, through corrupt memory or something else, manages to produce a garbage body which fails it's checksum but... somehow... is encrypted correctly. I've never seen that sort of problem.

The TCP checksum catches some issues but it won't detect everything. Other newer algorithms like CRC32C are much more effective at detecting corrupt data.

The following is an excerpt from Performance of Checksums and CRCs over Real Data[0].

The TCP checksum is a 16-bit ones-complement sum of the data. This sum will catch any burst error of 15bits or less[8], and all 16-bit burst errors except for those which replace one 1’s complement zero with another (i.e., 16 adjacent 1 bits replaced by 16 zero bits, or vice-versa). Over uniformly distributed data, it is expected to detect other types of errors at a rate proportional to 1 in 2^16.

If you're deeply interested in this topic then I would recommend Jonathan Stone's Phd thesis.

[0] https://www.researchgate.net/publication/3334567_Performance...

Reply on news.ycombinator.com