httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject breach attack
Date Tue, 06 Aug 2013 17:24:15 GMT

Has anyone given much thought to changes in httpd to help mitigate the
recently publicized breach attack:

>From an httpd perspective, looking at the 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?



View raw message