httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: breach attack
Date Sat, 10 Aug 2013 19:28:21 GMT
Am Freitag, 9. August 2013, 22:04:22 schrieb Joe Orton:
> On Fri, Aug 09, 2013 at 09:14:51AM -0700, Paul Querna wrote:
> > In this case, I don't know if any of the proposed mitigations
> > help;
> > I'd love to have an easy way to validate that, so we could bring
> > data to the discussion:  If it increases the attack by multiple
> > hours, and causes a <1% performance drop, isn't that the kind of
> > thing that is useful?
> 
> I sympathise with Stefan but I agree we should do something if we
> can find something cheap, effective and reliable.

Effective is difficult when done on the server. OTOH, browsers could 
just not send "Accept-Encoding: gzip" if a request is cross-domain and 
contains some sort of credentials (HTTP-auth, cookies with the 
'secure' attribute, client certificate, ...). I think that would stop 
the vast majority of attack scenarios. I very much doubt that any 
measure at the server side can achieve a comparable level of 
protection.

> Length hiding seems the most promising avenue.  The paper notes that
> that simply adding rand(0..n) bytes to the response only increases
> the cost (time/requests) of executing the attack.
> 
> Adding a random number of leading zeroes to the chunk-size line
> would be be perhaps reliable (i.e. least likely to have interop
> issues), though we could only introduce relatively small
> variability of the total response length.  We could maybe 0-5
> leading zeroes per chunk, safely? Possibly that breaks some client
> already.  It's probably not effective.

What do you think of including a header? Is there a way to find out 
from the encrypted traffic where the header ends and where the body 
starts? See my other mail, which I have sent before reading this one, 
unfortunately.


Mime
View raw message