httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: breach attack
Date Tue, 06 Aug 2013 17:32:00 GMT
On Tue, Aug 6, 2013 at 1:24 PM, Paul Querna <paul@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)

Mime
View raw message