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.
