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

2023年10月12日(木) 13:44 Martin Thomson <mt@lowentropy.net>:

> On Thu, Oct 12, 2023, at 15:38, Glenn Strauss wrote:
> > 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.)
>
> Unfortunately, in order to do that, we would need to define a completely
> new protocol that is identified by a different ALPN token, like
> "h2-but-not-as-vulnerable-to-DoS".
>
> I agree that the initial value is bad (a limit of 2^30 is just absurd),
> but I'm not sure that the cost of fixing this is justified.
>
> Teaching clients cope better with lower concurrency limits (like 8) is
> probably our best course of action here.
>
>
I'm not sure if it is a good idea to reduce the concurrency of the
connection, considering that the primary motivation behind the introduction
of HTTP/2 was to increase concurrency.

I might argue that the rapid reset is an attack against request processing
concurrency within a server, and that reducing concurrency at the
connection level is not the best way to mitigate that.

As stated, reducing connection-level concurrency has drawbacks when BDP is
large. It is also often insufficient as a protection against malicious
clients.

The example I like to talk about is slowloris. Even when we reduce
MAX_CONCURRENT_STREAMS to 10, one client would be capable of opening 10
streams at once, on each of them sending the request body at a slow speed.
It means that either applications running behind an HTTP/2 server have to
have 10x concurrency compared to HTTP/1, or that the HTTP/2 server has to
limit concurrency even further.

As Stephan and Willy are discussing [1][2], HTTP/2 servers tend to already
have throttling at the request processing level.

Assuming that is the case, my preference would be to advocate HTTP/2 server
developers make sure that that throttling scheme takes care of the rapid
reset attack.

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0028.html
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0029.html


-- 
Kazuho Oku