On Tue, Aug 6, 2013 at 10:38 AM, Steffen <[email protected]> wrote: > > Good instructive and advisable config: > > https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
Well, Forward-Secrecy is really about the NSA capturing your traffic and decrypting it later; the Breach attack stuff is about a chosen plaintext attack on compressed response bodies -- afaik they have not overlapping mitigations? But in general, we should rev our defaults in configuration to help with all of the above :) > > On Tuesday 06/08/2013 at 19:24, Paul Querna wrote: >> >> Hiya, >> >> Has anyone given much thought to changes in httpd to help mitigate the >> recently publicized breach attack: >> >> http://breachattack.com/ >> >> From an httpd perspective, looking at the mitigations >> <http://breachattack.com/#mitigations> >> >> 1) Disabling HTTP compression >> 2) Separating secrets from user input >> 3) Randomizing secrets per request >> 4) Masking secrets (effectively randomizing by XORing with a random >> secret per request) >> 5) Protecting vulnerable pages with CSRF >> 6) Length hiding (by adding random amount of bytes to the responses) >> 7) Rate-limiting the requests >> >> >> Many of these are firmly in the domain of an application developer, >> but I think we should work out if there are ways we can either change >> default configurations or add new features to help application >> developers be successful: >> >> 1) Has anyone given any thought to changing how we do chunked >> encoding? Chunking is kinda like arbitrary padding we an insert >> into a response, without having to know anything about the actual >> content of the response. What if we increased the number of chunks we >> create, and randomly placed them -- this wouldn't completely ruin some >> of the attacks, but could potentially increase the number of requests >> needed significantly. (We should figure out the math here? How many >> random chunks of how big are an effective mitigation?) >> >> 2) Disabling TLS Compression by default, even in older versions. >> Currently we changed the default to SSLCompression off in >=2.4.3, I'd >> like to see us back port this to 2.2.x. >> >> 3) Disable mod_default compression for X content types by default on >> encrypted connections. Likely HTML, maybe JSON, maybe Javascript >> content types? >> >> Thoughts? Other Ideas? >> >> Thanks, >> >> Paul > > > >
