- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 11 Oct 2023 12:09:28 +0200
- To: Stefan Eissing <stefan@eissing.org>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Stefan, On Wed, Oct 11, 2023 at 12:06:19PM +0200, Stefan Eissing wrote: > > > Am 11.10.2023 um 11:42 schrieb Willy Tarreau <w@1wt.eu>: > > > > As such, I suspect that these approaches might be much more common than > > what sensationalist mass media want us to believe and that the issue is > > more a matter of implementation choices (i.e. resource management) than > > of the protocol. > > Apache httpd tracks the "active" streams, that are actually being processed > and occupy limited server resources. When a client RSTs an active stream > *before* response headers have been read, httpd will lower the "max active" > streams of the connection. > > There are also mechanisms to raise this limit again, should the client > start to behave nicely. > > In the discussed attack pattern, httpd will rapidly limit such a connection > to 2 active streams. RSTing one of those active streams will only allow another > stream to proceed once all the resources of the former one have been freed. In > the case of a proxied backend, this might take considerable time. > > RSTing a stream that has not started processing just triggers the book-keeping > to update. So the attack will cause some cpu consumption on the lower level > protocol layer, but not much more than other frames would. > > Therefore, my conclusion is that Apache httpd is not affected by this > in any security relevant way. I noticed a message where you described this approach and I like it, it very likely allows to automatically adapt to bogus/nasty clients. I think we should really start to check how many stacks are not affected given the noise that's being done around this :-/ Thanks! Willy
Received on Wednesday, 11 October 2023 10:09:55 UTC