[HN Gopher] HTTP/2 Continuation Flood: Technical Details
___________________________________________________________________
HTTP/2 Continuation Flood: Technical Details
Author : campuscodi
Score : 187 points
Date : 2024-04-04 14:32 UTC (8 hours ago)
(HTM) web link (nowotarski.info)
(TXT) w3m dump (nowotarski.info)
| tzot wrote:
| I just love this typo:
|
| > After serveral retries
| skywhopper wrote:
| Nice writeup and great find! Kudos to the author for taking such
| a broad approach and responsibly reporting their findings and
| finally for sharing the details in such a readable way.
| nullindividual wrote:
| Previous article with impacted web servers/reverse proxies from
| the same author.
|
| https://nowotarski.info/http2-continuation-flood/
| pmlnr wrote:
| Now do this slowly, and you can call it slowloris v2 :(
| mcmatterson wrote:
| I'd just mitigated this exact thing in Bandit last month!
|
| https://github.com/mtrudel/bandit/blob/main/lib/bandit/http2...
|
| TBH, from an implementors perspective this is a super obvious
| thing to cover off. It had long been on my radar and was
| something that I'd always figured other implementations had
| defended against as well.
| hinkley wrote:
| Well you know what happens when we assume. You make a front
| page headline out of you and me.
| jagger27 wrote:
| > NOT affected: Nginx, Jetty, HAProxy, NetScaler, Varnish. [0]
|
| 0: https://nowotarski.info/http2-continuation-flood/
| bklyn11201 wrote:
| What about Caddy? It's a great project that deserves it's own
| line ;)
| programd wrote:
| On Ubuntu 22.04 LTS caddy from the Ubuntu apt repo is shown
| as on version 2.7.6 and built with Go 1.21.5. That version of
| Go does not have a fix for this issue. Caddy 2.7.6 is also
| the latest version released on GitHub.
|
| So no fix yet, but I think all that's needed is a recompile
| with the latest version of Go 1.22.2
| nelse wrote:
| I think that recompiling with upgraded Go will not solve
| the issue. It seems Caddy imports `golang.org/x/net/http2`
| and pins it to v0.22.0 which is vulnerable: https://github.
| com/caddyserver/caddy/issues/6219#issuecommen....
| thegeekpirate wrote:
| Looks like it's been fixed if you recompile from master
| as of a few minutes ago
| shuntress wrote:
| HTTP/2 or How to Cram a Transport Layer "Upgrade" Into an
| Application Layer Protocol.
| syncsynchalt wrote:
| HTTP/2 still suffers from most of the problems of TCP (ordered
| packet requirement, head-of-line blocking, number-line acks).
| The only new TL-like feature that it adds is connection
| multiplexing.
|
| It's HTTP/3 that really ups the Transport Layer game, by
| tunneling a truly new layer (QUIC) through UDP packets.
| unethical_ban wrote:
| This has been at the top all day.
|
| I wonder: For low-traffic websites, is it possible that running
| HTTP/1.1 is just safer?
| dexwiz wrote:
| 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.
| graemep wrote:
| I was wondering about that. It is more mature an less complex
| so it seems probable it is safer.
| akira2501 wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-04 23:00 UTC)