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

I would chalk it up as a concern and place this (very nice) advice
in the Security Considerations section.

....Roy


On Mar 2, 2012, at 4:01 AM, Mike Belshe wrote:
> Let's examine the details of zlib and its format.  I believe there is no practical amplification attack.  Maybe you'll prove me wrong.
> 
> zlib is quite simple.  You can scan it.  You can sanity check it.  You can verify lz77 dictionary entries and ban any sequences that grow too long (100B?).  On top of that we're compressing highly structured data, so we know what the decompressed data must look like.  So if the decompressed data ever falls out of whack, you can nuke it there too, as you stream it.
> 
> Short input sequences will be discardable off the bat - none of this "give me 6 bytes to make me process 5KB" is going to be possible - you'll have to send a sizable request to get us to process much out of it.  Then, if individual dictionary entries grow unreasonably large in the first chunk of headers (100B?), we'll drop you.  If the expanded name value pairs grow too large, we'll drop you.  Or if it looks like you're sending junk headers or unreasonable values, we'll drop you there too.  An attacker might be able to convince a server to decompress 1000B on a 200B input before detecting the fraud, but even that seems unlikely if we verify at all the levels I mentioned already.  
> 
> For argument's sake, lets be generous and pretend its even a 10x attack on a 100B input.  Note well that the attack does not scale - even if you can turn 100 bytes into 1000 bytes processed, it does not mean that you can send us 10K to get 100K processed.   Because the length caps are going to be really small, as soon as we see too many bytes, we'll be dropping you, decreasing your amplification.
> 
> All in all, to get our SPDY server to process 1KB of amplified data on your 100B sent, you had to do a full 3 way handshake, plus a full SSL handshake (with PK op on your *client*, and we got to pick which type of PK op - 8192bit RSA anyone?).  Mice nuts!  You'd be better off attacking with legitimate requests - most servers will use far more resources trying to process legit requests than deflating that extraneous 1KB of data.
> 
> See what I mean?  Because the size is bounded and because the amplification is easily capped, the attack is not an attack at all.
> 
> Mike

Received on Friday, 2 March 2012 21:32:43 UTC