W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: Denial of Service using invalid Content-Length header

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 21 Jun 2011 00:18:54 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Jan Starke <jan.starke@outofbed.org>, ietf-http-wg@w3.org
Message-ID: <20110620221854.GQ2897@1wt.eu>
On Tue, Jun 21, 2011 at 10:05:49AM +1200, Adrien de Croy wrote:
> 
> I think the inference was that some servers will struggle to provide 
> service to others when they maintain 30.000 idle connections.

This is less and less common with todays hardware. Having been involved
10 years ago in designing an infrastructure that was able to support 10k
concurrent users with Apache 1.3 as the first gateway, I remember how hard
it was to support even a few thousands of concurrent connections on a
server with 1-2 gigs of RAM at this time. Now common sizing for medium-
sized servers are 32, 48 or even 64 gigs, and I know quite a bunch of
people working in DCs who are used to buy that as the default hardware.
Even with Apache 1.3, this allows you to reach such high numbers with
some careful tuning.

> But in the end, I don't see any real difference between sending the POST 
> or even just sending nothing.

Agreed. It's similar to when the server is waiting for the end of
headers for starting processing.

> The server will have some sort of timeout.  It might be a different 
> timeout used for waiting for anything vs waiting for a completion of a 
> POST message body.

Yes that clearly is common and mandatory anyway. You can't rely on the
OS only to kill the connections for you, as most default timeouts are
much too large.

> but I think the timeout in general will be long enough for many 
> connections to have been initiated.

Indeed, which is why I was explaining the change that was made possible
with RAM sizing nowadays.

> Things that mitigate that are features like connection rate limiting 
> (per source IP), per-IP overall concurrent connection limits etc.

I 100% agree. That's the most efficient solution but not all servers are
able to do that. Still that's what the antiloris module was doing :-)

Cheers,
Willy
Received on Monday, 20 June 2011 22:19:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:41 GMT