Hacker News Reader

Comment by tambourine_man | Hacker News Reader

What’s great about HTTP 1.1 is it’s simplicity. I mean, you can explain it to a complete newby and have that person write a functioning implementation in a few lines of shell script, all in one afternoon.

In fact, you can probably figure it out by yourself just by looking at what goes across the wire.

And yet, it runs the whole modern world. That’s beautiful. I think simplicity is underrated and it’s something I really value when choosing the tools I use.

View on HN

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

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.

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

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 [...]"

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.

HTTP/1.1 is so simple that I can just open up netcat and ask a webpage from a website by hand. And this is not even my field.

Now, you can also build a lot of complexity upon it. And while the simplicity is nice for inspecting and debugging sometimes, in practice it is rarely used, and it's a very complex beast with TLS, SSL, gzip compression and more.

The arguments are similar to binary logs vs text logs. Except that in HTTP's case, it is already littered with binary.

The case for "http is simple" similarly falls apart when you realize that a lot of tools for diagnosing http streams can just as easily (easier in fact) consume a binary stream and translate it into a human readable form as they can analyze the text form.

We don't complain that we can't read our browser's binary but for some reason everyone is convinced that our transport protocols are different and it is imperative to be able to read it with a tool to translate it.

I’m pretty sure I’ll never understand QUIC completely in my lifetime. I do know HTTP 1.1 through and through (it’s really easy).

The fact that HTTP 1.1 speeds are even comparable, let alone faster in some situations, should at least tip the scale in its favor.

obscure standards mean less possibility that someone else without google-scale resources will implement their own client/server.

And that is one of the key "benefits" of HTTP/3 if you're a Google-scale company.

Except there are already several such implementations and nobody is going to deprecate older HTTP versions.

Chrome has an overwhelming portion of the web browser installed base. It's full of dark patterns and scary warnings about "dangerous" things like unencrypted HTTP. I don't have a lot of faith that they're not going to disable older HTTP versions at some point.

There are many implementations of QUIC already, its quite diverse...

> The fact that HTTP 1.1 speeds are even comparable, let alone faster in some situations, should at least tip the scale in its favor.

Are these realistic web browsing scenarios? Because that seems false. For most websites http/2 is a pretty significant performance win.

Are you sure you "know" HTTP 1.1 through and through?

How much do you understand about gzip or brotili? How much do you know about TLS? Do you understand all of the functionality of TCP? Network congestion and checksuming?

QUIC includes compression, encryption, and transport into the standard which is why it's more complicated. Just because Http 1.1 doesn't include those parts explicitly into the standard, doesn't mean they are unused.

Http 1.1 is only "easy" because it sits atop a sea of complexity that rarely faces the same critiques as Quic does.

> I’m pretty sure I’ll never understand QUIC completely in my lifetime.

Do you understand how to build TCP packets by hand? A lot of the confusion between QUIC and HTTP/3 is intentional because it is somewhat merging the layers that used to be entirely separate.

All the examples elsewhere of "I can telnet/netcat to an HTTP/1.1 server and mostly do the thing" avoid the obvious fact that telnet/netcat is still doing all the work of splitting the messages into TCP packets and following TCP rules.

Presumably QUIC and HTTP/3 are separate enough to still warrant the idea of a telnet/netcat for QUIC taking care of the low level details and then you could try to write HTTP/3 on top of those apps a little easier, in a similar fashion. Though maybe not, without the rich history of telnet-related protocols on top of TCP and HTTP/3 still currently the only protocol targeting QUIC today.

Comparing HTTP/1 to QUIC is apples to oranges. You would need to compare HTTP/1.1 to HTTP/3. And QUIC to a combination of TCP and TLS. Do you understand those through and through too - or are you just utilizing libraries to make them work?

HTTP/3 is actually not super complex. The main trickiness comes from header compression. But unlike HTTP/2 the stateful QPACK compression part in HTTP/3 can actually be deactivated, and just the stateless static dictionary and huffmann compression being used.

> What’s great about HTTP 1.1 is it’s simplicity.

Perhaps I'm old fashioned, but I like being able to debug things with telnet/netcat. (Or openssl s_client.)

Isn’t this mostly a complaint about tooling? If getting the text form of a message just meant piping to a command would it be fine?

To me, the fact that it seems simple to roll your own HTTP 1.1 implementation is more of a downside than an advantage.

> What’s great about HTTP 1.1 is it’s simplicity.

This is an underappreciated feature of the old protocols. You can telnet into an HTTP, SMTP, POP, or even IMAP server and talk to it with your keyboard (using stunnel for the encrypted versions), or dump the traffic to learn the protocol or debug a problem. Good luck doing that with QUIC.

For the second part, using wireshark is really not that big a jump in skill level and an easy way to debug the protocol (provided you get past the encryption)

Might want to try using tools from this century. We live in a post-curl, post-Wireshark world. There's no need to create excess waste heat parsing and unparsing "plain text" (lol, there is no such thing) protocols anymore; and anyways with SSL virtually mandatory it's not like it stays human readable over the wire. Fast, efficient, open binary protocols ftw!

In that sense, HTML also "runs the whole modern world".

If you're talking about HTTP 1.1 and not thinking about the complexity of TLS, you're ignoring more than half the LoC in the stack.

I like QUIC because I was never going to roll my own TLS anyway, so I might as well have TLS and streams in the same package.

It's not worth it to trade simplicity for performance or efficiency. Especially if the energy that is being wasted on simpler things is coming from fossil fuels.

Reply on news.ycombinator.com