httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: TLS renegotiation attack, mod_ssl and OpenSSL
Date Thu, 05 Nov 2009 20:38:23 GMT

On 11/05/2009 06:32 PM, Joe Orton wrote:
> On Thu, Nov 05, 2009 at 03:39:06PM +0000, Ben Laurie wrote:
>> Joe Orton wrote:
>>> In the short term, I think it would be useful to have a new SSL_OP_* 
>>> flag which enables rejection of a client-initiated handshake in an SSL 
>>> server.  This will fix the issue for 90% of sites without breaking the 
>>> remaining 10% (case 3 above), and is a change that can be deployed 
>>> everywhere.
>> Case 3 is vulnerable to attack, though, so I'm afraid you want to break it.
> Sites depend on per-dir-reneg and people will simply not upgrade if we 
> break that - I have tried the "don't do that" response for per-dir-reneg 
> issues enough times over the years that I'm reasonably confident of 
> this.  (Also I'm told that the Postgres SSL support depends on being 
> able to do a periodic reneg, in the wider context)
> Being able to ship a 90% solution now and working on the proper fixes 
> for the remaining 10% is valuable, I think.

I agree with Joe here. See the lengthy discussions we had regarding POST bodies
handling in mod_ssl during renegotiation at

If server triggered renegotiation will not work at all, people will just ignore the
update or remove it from 0.9.8l in their self patched versions.
So overall I guess we would be safer with an approach that

1. Turns off renegotiation (server and client) by default.
2. Allows to turn on server and client triggered renegotiation in a way as proposed
   by Joe.
3. Allow to turn on server triggered renegotiation by a compile time option.

1. This way openssl ships save by default.
2. Consumers of the library can decide to overwrite this behaviour.
3. Packagers can decide to deliver only a "90%" solution if they do not want / cannot
   modify all consumer packages that need server triggered renegotiation.

Some of the attacks rely on specific HTTP mechanisms like connection keep alives and
pipelining. So we might be able to find patches for mod_ssl to solve these specific



View raw message