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: Mon, 20 Jun 2011 23:19:11 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Jan Starke <jan.starke@outofbed.org>, ietf-http-wg@w3.org
Message-ID: <20110620211911.GL2897@1wt.eu>
On Mon, Jun 20, 2011 at 05:03:32PM +0000, Poul-Henning Kamp wrote:
> In message <20110620163813.GA12762@1wt.eu>, Willy Tarreau writes:
> >I would add that the *first* protection obviously is to have the
> >server correctly implement timeouts, because if it is sensible to
> >this attack, it's also sensible to simple client failure.
> There is no possible timeout value which will both serve slow clients
> in bad connectivity (iPhone4 ?) and prevent DoS attacks.

Yes in practice you can because even with bad connectivity you're generally
interested by covering holes as large as 30-60 seconds, not much more. After
that, many other stateful components between the client and the server will
have cut the connection anyway. For instance, most haproxy setups use between
20 and 30 seconds and don't report any particular issue. Those using larger
values generally try to cover long application response times and make use
of the same timeout for all values to keep their configs simple.

And with a 30 seconds timeout, even if you're able to send 1000 connections
per second, which is quite not possible with a simple xDSL line, that's still
only 30k concurrent connections, which is quite small to medium for todays

Clearly I'm not speaking about DDoSes here, botnets have virtually unlimited
bandwidth, and they don't care about doing anything smart such as trying to
fool your content-length. I'm just talking about the "easy DoS" that any joe
user might ignite from his own access. Slowloris typically was such one. A
variant can be made to work with POST requests by sending one byte at a time
before the idle timeout strikes, unless the server supports a total transfer
timeout too.

Received on Monday, 20 June 2011 21:22:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC