httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Montague <>
Subject Re: [users@httpd] Disabling client initiated renegotiation
Date Sun, 10 Apr 2011 01:46:51 GMT
  Thanks for the background information.  Once I understood the the 
reasons behind what you're asking, I looked at the temporary-workaround 
patches to both OpenSSL and Apache HTTP Server from the time 
CVE-2009-3555 was published, since my memory said that the workarounds 
were to disable client renegotiation.  I think it is actually better to 
disable client-initiated renegotiation in OpenSSL rather than in Apache 
HTTP Server, since an OpenSSL based solution will prevent TLS based DoS 
attacks in other protocols, too (LDAPS, IMAP, SMTP, FTPS, ...)    
However, since this is the Apache HTTP Server mailing list, here is what 
I found relating to httpd:

It looks to me like httpd rejects client-initiated TLS renegotiation 
out-of-the-box and hence you should not need to do anything in order to 
achieve your goal.

I'm running httpd 2.3.12-dev (2011-03-10 snapshot from SVN) with OpenSSL 
1.0.0d-fips under Fedora 14; but I've also checked the httpd 2.2.17 
source code (see below for details).

I followed the instructions at 
for testing to see if client-initiated TLS renegotiations are allowed.  
My test indicates that client initiated renegotiations are rejected:

$ openssl s_client -connect
[...lots of output omitted...]
     Protocol  : TLSv1
     Cipher    : DHE-RSA-AES256-SHA
[...more output omitted...]
GET / HTTP/1.0
140716401080128:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl 
handshake failure:s3_pkt.c:590:

I also repeated the above test with the -ssl3 option to "openssl 
s_client" which gave the same results.

Can you do this test on your end and let me know if you get different 
results?  If you discover that your installation of Apache HTTP Server 
accepts client-initiated TLS renegotiations, please include the

I've also investigated the source code for Apache HTTP Server 2.2.17 and 
compared it to the temporary workaround patch for CVE-2009-3555.

Here is the announcement of the temporary workaround:

Here is the patch for the temporary workaround:

I've gone through the source code for Apache HTTP Server 2.2.17 and it 
looks to me like everything from the temporary workaround is still in 
place.  In particular, the last part of the patch adds a 
ssl_callback_Info() function (see the file 
modules/ssl/ssl_engine_kernel.c lines 1926 - 1970) which disallows any 
client-initiated renegotiations after the initial handshake has been 

So hopefully you won't need to do anything on your end, at least not as 
far as TLS renegotiation DoS attacks against Apache HTTP Server are 

   Mark Montague

On April 9, 2011 20:27 , Chris Hill <> wrote:
> Nothing wrong with re-negotiation if used for what it was intended. 
> Now, since a server cannot limit how many of these a client can 
> request, this leaves the doors open to abuse (DoS --not to be confused 
> with DDoS).
> To me, disabling it would be as good as limiting how many times a 
> client can request renegotiation.
> There are actual attacks taking advantage of it, and security vendors 
> (IDS/IPS) are already working on ways to detect these. However, 
> vendors are falling behind when it comes to providing a good solution 
> that can allow system administrators to limit user's trying to take 
> advantage of this.
> If you are serious about this and want to provide a solution to 
> disable re-negotiation altogether, I would share more info on how this 
> is being exploited.
> Chris.
> On Sat, Apr 9, 2011 at 7:37 PM, Mark Montague < 
> <>> wrote:
>      On April 9, 2011 18:00 , Chris Hill <
>     <>>  wrote:
>         My company relies on Apache for a number of customer facing
>         sites. What's a reliable way to disable client initiated
>         renegotiation (both secure and insecure renegotiation)?. I
>         know one specific openssl library (l) disables this, but then
>         later ones enable "secure" renegotiation, which we need to
>         disable.
>         Ideally, I'd like a solution through an configuration
>         parameter so that future versions/upgrades do not re-enable
>         renegotiation.
>     I don't have an answer for you, but, out of curiosity, why do you
>     need to disable SSL 3.0 / TLS renegotiation?  If a client
>     initiates a renegotiation, is this bad in some way?  Obviously,
>     you trusted the client during the initial negotiation/handshake.
>     --
>      Mark Montague
> <>

   Mark Montague

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message