- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 12 Oct 2023 20:57:39 +0200
- To: Mike Bishop <mbishop@evequefou.be>
- Cc: Martin Thomson <mt@lowentropy.net>, Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Mike, On Thu, Oct 12, 2023 at 06:33:26PM +0000, Mike Bishop wrote: > That might be exactly what we need. This has been a problem for many of us > for a while, despite it being publicly discussed only recently. While your > draft is a fine patch for well-behaved clients, the reality is that attackers > will simply play dumb and pretend to be unextended HTTP/2 clients. Not if you combine it with settings like I suggested earlier in the thread: 1) send SETTINGS with MAX_CONCURRENT_STREAMS=100 2) send MAX_STREAMS announcing 100 streams (e.g. max_stream_id=201) 3) send SETTINGS with MAX_CONCURRENT_STREAMS=10 (or even less) At this point if you get a new stream with an ID higher than the MAX_STREAMS you advertised and the total is above MAX_CONCURRENT_STREAMS, you know for certain it's an abuse. > Other > mitigations will still be needed as long as that connection pattern is > allowed. (And reducing the default or recommended value does nothing to > mitigate this particular attack, so I'm not particularly concerned about it. > Servers will enforce their actual value from the start of the connection and > RESET and excess streams anyway.) Servers can (and should) use their *real* stream count and not just the apparent one at the protocol level. Apache, Nginx and Haproxy all have their own variants of this and cope well with this situation. Regards, Willy
Received on Thursday, 12 October 2023 18:58:01 UTC