W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Fri, 02 Mar 2012 21:22:32 +0100
Message-ID: <1330719752.1807.93.camel@home.hno.se>
To: Willy Tarreau <w@1wt.eu>
Cc: ietf-http-wg@w3.org
fre 2012-03-02 klockan 15:11 +0100 skrev Willy Tarreau:

> This is the point where you need to decompress the stream to parse the
> headers. Even if zlib may be used as a stream, I think you'll agree that
> in the sake of efficiency, you'll try to decompress as much of it as
> possible at once, you won't call inflate() many times with a short output.

No, but most will be using zlib, and there the output buffer is
allocated by the caller and any output will not explode beyond what the
caller is accepts to handle.

> Since these requests are valid, the connection has no reason for being
> dropped. The attacker will simply emit a stream of many such requests
> and will receive a stream of "404 not found" for instance.

Can even be valid requests for valid resources, with compression applied
to standard "junk" headers such as Accept, making it even harder to
notice what is going on.

> Another concern with this high compression ratio coupled with pipelining is
> that it becomes easier to send a huge number of requests to a server in just
> a few bytes. With the example above, we're saying that both the gateway and
> the server may have to process 10000 8kB requests per second from a single
> ADSL line. As of today, doing this for an attacker still requires at least
> 260 Mbps of upstream bandwidth.

It will in most cases get throttled by the downstream bandwidth and to
some extent by how much the server accept to process concurrently per
client. But yes, for example a highly compressed stream of HEAD requests
for similar resources would result in a as highly compressed stream of
responses.

Regards
Henrik
Received on Friday, 2 March 2012 20:23:20 GMT

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