On Tue, Aug 6, 2013 at 10:32 AM, Eric Covener <cove...@gmail.com> wrote: > On Tue, Aug 6, 2013 at 1:24 PM, Paul Querna <p...@querna.org> 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?) > > Another option in this neighborhood is small/varying deflate blocks. > But that probably limits the usefulness of deflate to the same extent > that it helps. The idea is to make it less likely that the user input > and secret get compressed together. > >> >> 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. > > I think it recently made it to 2.2.x, post the last release. > >> >> 3) Disable mod_default compression for X content types by default on >> encrypted connections. Likely HTML, maybe JSON, maybe Javascript >> content types? > > In the code, or default conf / manual? It's the cautious thing to do, > but I'm not yet sure if making everyone opt back in would really mean > much (e.g. what number would give their app the required scrutiny > before opting back in)
In the code. Configurations take order of magnitude more years to trickle down to vendors compared to a code change... :-)
