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
