Re: Disabling client initiated renegotiation

Mark Montague <mark@xxxxxxxxxxx> · Sat, 09 Apr 2011 21:46:51 -0400

 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 

http://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html 

for testing to see if client-initiated TLS renegotiations are allowed.  

My test indicates that client initiated renegotiations are rejected:

$ openssl s_client -connect f14dev1.catseye.org:443
[...lots of output omitted...]
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
[...more output omitted...]
GET / HTTP/1.0
R
RENEGOTIATING

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:  

http://marc.info/?l=apache-httpd-announce&m=125755783724966&w=2

Here is the patch for the temporary workaround:  

http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch

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 

completed.

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 

concerned.

--
  Mark Montague
  mark@xxxxxxxxxxx

On April 9, 2011 20:27 , Chris Hill <chris.hillsec@xxxxxxxxx> 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 <mark@xxxxxxxxxxx 

<mailto:mark@xxxxxxxxxxx>> wrote:

     On April 9, 2011 18:00 , Chris Hill <chris.hillsec@xxxxxxxxx
    <mailto:chris.hillsec@xxxxxxxxx>>  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@xxxxxxxxxxx <mailto:mark@xxxxxxxxxxx>

--
  Mark Montague
  mark@xxxxxxxxxxx

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx