HTTP/2 Continuation Flood: Technical Details

Upgrading merely to upgrade is not good engineering practice. If you expect to receive no additional benefits from the upgrade then it is probably not justified.

HTTP/1.1 is far easier to implement, thus it is reasonable to assume it should contain fewer bugs.

HTTP/2 (and HTTP/3) is vastly different in features (added multiplexing, windowing, HPACK etc). All this transforms a largely stateless connection (in the HTTP/1.1 case) to a stateful one. And in order to maintain the stateful connection, you need to store some data (state, configuration etc), thus all these problems.

Also, in HTTP/2, since multiplexing is added, the protection characteristics are different. For example, if the connections were generated by CDN source draws, you may just allow fewer number of connections each with a large pool of multiplex channels, but if the connections were from direct user access, you may then want to allow large number of connections, but each with fewer number of multiplex channels. In HTTP/1, protection is much simpler, since everybody looked almost the same.

Not necessarily. Everyone saying HTTP/1.1 is simple has never implemented a full real-world-compatible parser for it.

HTTP/1 has lots of unobvious edge cases, and legacy quirks. Text format has way more flexibility than it seems from valid headers. It has obscure features like multi-line headers and old MIME features, 100-continue race conditions, custom hop-by-hop headers, GET bodies.

Fortunately new HTTP RFCs document many pitfalls. If you just implement what RFC 2616 said, you won't have a safe implementation.

Actual size of a request or response can be specified in multiple ways (at the same time, with conflicting values), and depends on a combination of several features, and values of headers with weird parsing rules needed for backwards compat, so "simple" HTTP implementations can be tricked into request smuggling.

Either way you need a robust, well-tested mature implementation.

I was wondering about that. It is more mature an less complex so it seems probable it is safer.

Probably. HTTP/2 is good for streaming, and even that is being replaced by newer protocols.

For normal asset serving the only advantage is more assets can be loaded in parallel since HTTP/1 is limited on connections per domain. CDNs on different domains usually prevent this from being an issue.

In theory you could serve unbundled JS assets via HTTP/2, but I have never seen it in production. Likely because you still need a compilation step most of the time.

Well you know what happens when we assume. You make a front page headline out of you and me.

What about Caddy? It's a great project that deserves it's own line ;)

In other words the ones that have long been contesting the use of CONTINUATION due to the risk of DoS 10 years ago. Just read any of the long threads there to get an idea, it's always about how to avoid the nasty CONTINUATION: https://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep...

If at least it had been accepted to forbid it after a non-full HEADERS frame it would have been more robust but it was perceived that the encoding job itself could have been harder (byte boundaries in compressors etc).

BTW I find it funny how we "rediscover" the same stuff every 10 years. Recently it was the well-known RESET_STREAM flood, now the CONTINUATION, soon it will probably be DATA frames of length zero, then single-byte WINDOW_UPDATES, then INITIAL_WINDOW SETTINGS that cost a lot of CPU, etc. The world is just circling in this security circus, provided it's possible to assign a name and possibly a logo to a known problem...

The issue is that people constantly focus on and optimize for the happy path, but don't stop and think about what would happen if an adversary deliberately and repeatedly triggered the worst case scenario. So many denial-of-service attacks (slowloris, query parameter hash collisions, etc.) come into fruition because bounded resource usage is an afterthought.