Re: Prague side meeting: HTTP/2 concurrency and request cancellation (CVE-2023-44487)

On Thu, Oct 12, 2023 at 10:31:50AM +1100, Martin Thomson wrote:
> On Wed, Oct 11, 2023, at 20:42, Willy Tarreau wrote:
> > Or maybe something like this could work:
> >
> >    MAX_CONCURRENT_STREAMS = 100
> >    MAX_STREAMS = 100
> >    MAX_CONCURRENT_STREAMS = 10
> >
> > Older clients would learn 100 then 10, possibly dropping excess
> > streams, while new clients would learn MAX_STREAMS=100 and from
> > that point ignore MAX_CONCURRENT_STREAMS=10.
> 
> That's exactly the idea.  You could just start with MAX_CONCURRENT_STREAMS=10 as well, though you should be aware that some clients might choke when this value is less than 100, so your approach is probably the safest.

Related, I support a future RFC changing the initial setting for HTTP/2
SETTINGS_MAX_CONCURRENT_STREAMS to something much more limited,
such as 10.  (FYI: lighttpd sends SETTINGS_MAX_CONCURRENT_STREAMS 8.)

RFC 9113: "Initially, there is no limit to this value.  It is
recommended that this value be no smaller than 100, so as to not
unnecessarily limit parallelism."

With a defined limit of 10, servers could then choose to increase
SETTINGS_MAX_CONCURRENT_STREAMS to 100 in the initial SETTINGS frame
sent to clients, or could choose to set MAX_STREAMS.  Yes, there might
be older clients which assume at least 100, but those older clients
would reduce their numbers over time after RFC guidance is updated.

Having such a lower limit would more easily allow servers to distinguish
request flood attacks (keeping the request pipeline full) from
legitimate traffic.  The current initial value of (unlimited) for
SETTINGS_MAX_CONCURRENT_STREAMS makes this more murky.  Since an
attacker can avoid sending SETTINGS acknowledgement, a server can not
rely on receiving a SETTINGS acknowledgment before enforcing a lower
concurrent streams limit, and so a server must use other heuristics.

Cheers, Glenn

Received on Thursday, 12 October 2023 04:39:01 UTC