On Tue, Aug 6, 2013 at 1:32 PM, Eric Covener <[email protected]> wrote:
> On Tue, Aug 6, 2013 at 1:24 PM, Paul Querna <[email protected]> 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. > A filter could vary the size of what goes down the filter chain impacting deflate blocks or chunk sizes or SSL compression, at some extra expense. Some rule-based introspection into the response could provide guidance in some situations ??? Isn't that a strength of mod_security? > > > > 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) > -- Born in Roswell... married an alien... http://emptyhammock.com/
