httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: breach attack
Date Fri, 09 Aug 2013 16:14:51 GMT
On Fri, Aug 9, 2013 at 12:11 AM, Ruediger Pluem <> wrote:
> Stefan Fritsch wrote:
>> Am Dienstag, 6. August 2013, 10:24:15 schrieb Paul Querna:
>>> 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:
>> IMNSO, we are way past the point where we should patch up even more
>> issues that are caused by the broken security module of web browsers.
>> Instead, browsers vendors should fix this issue, for example by
>> offering a way to easily opt out of sending credentials with cross-
>> domain requests (maybe analogous to Strict Transport Security).
>> I am against putting any mitigation measures into httpd that adversely
>> affect normal use, like adding chunk extensions that will likely break
>> lots of clients, or like making mod_deflate much less efficient.
>> Though if somebody comes up with a clever scheme that has no negative
>> side effects, that would be of course fine. Or if we add some rate
>> limiting facility that would be useful for many purposes.
> +1. Well put.

I strongly disagree.

We are a component in an ecosystem that consists of Browsers and Servers.

We are part of that broken security model, even if the root cause is
from the browsers.

In this case, I don't know if any of the proposed mitigations help;
I'd love to have an easy way to validate that, so we could bring data
to the discussion:  If it increases the attack by multiple hours, and
causes a <1% performance drop, isn't that the kind of thing that is

We should strive as a community help, not to just throw the browsers
under the bus.

View raw message