SSL/TLS renegotiation vulnerability: how to disable on webservers & mitigations

I think this vulnerability has CVE# CVE-2009-3555.

Besides IPS (which some vendor don't have signatures for it as I was told the nature of
detection logic is still rather lacking though I don't know how Deep Security managed
to produce a signature for it in 2009), what are the ways to mitigate?

I was told web servers with ssl/openssl can be configured such that they are not vulnerabile.
Kindly provide detailed steps on how to do this for Apache (& Oracle Web server) & IIS

I was told modern browsers are protected against it: kindly let me know any specific settings
we need to set in IE, Firefox & Chrome to protect against this or is this something built into
the browser?

L09 - SSL / TLS renegotiation vulnerability
The server encrypts traffic using SSL / TLS, but allows a client to renegotiate the connection after the initial handshake.  As the server does not appear to limit the number of renegotiations for a single SSL / TLS connection, a client may open several simultaneous connections and repeatedly renegotiate them, which may possibly lead to a DoS condition
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David Johnson, CD, MVPOwnerCommented:
this is an old vulnerability and most products have updates that cover this i..e openssl / iis
Dave BaldwinFixer of ProblemsCommented:
David Johnson is correct, every product I know of has had updates to fix that.  IIS has never used OpenSSL and has never been vulnerable to this problem.
sunhuxAuthor Commented:
Ok, for Apache, is there a specific command to fix this?  Was told by Redhat
they don't release patches for it, so have to do a certain configuration in
Apache to address it,  any idea how this is done?
sunhuxAuthor Commented:

Was told by Redhat  they don't release patches for it (ie for RHEL 5.x)
though they did release patches for RHEL 6.x for Apache
btanExec ConsultantCommented:
A1/A2 - Default is to patch as the fixes are already available ...otherwise besides signature based, consider also disabling SSL Renegotiation in servers where possible, otherwise other intermediary handling HTTP traffic e.g. Web app FW or web gateway (e.g. Netscalar or F5 LTM) may be able to detect reneg transaction to reject those..

.... to be on safe side, the best soln is to patch servers and also catch the various related systems on workaround, if they recommended if the RFC5746 (that address this vulnerability - patch is not readily done yet

Apache HTTP Server 2.0.64 Released -
Download -

OpenSSL - Version 0.9.8m and later -

Microsoft - Security update MS10-049 - and

Oracle -,

Just a snaphot like the case of the SunJSSE implementation re-enables renegotiation by default for connections to RFC 5746 compliant peers.  
That is, both the client and server must support RFC 5746 in order to securely renegotiate. SunJSSE provides some interoperability modes for connections with peers that have not been upgraded, but users are strongly encouraged to update both their client and server implementations as soon as possible.

mode                                       allowLegacyHelloMessages      allowUnsafeRenegotiation
Strict                                       false                                               false
Interoperable (default)       true                                               false
Insecure                                       true                                               true
A3 - I will only say patch to the latest as all modern browsers have been updated to comply with this RFC 5746. But of course if server does not support the RFC and client does, the session will not be established so be wary on this as well
However, it is expected that many TLS servers that do
   not support renegotiation (and thus are not vulnerable) will not
   support this extension either, so in general, clients that implement
   this behavior will encounter interoperability problems.  There is no
   set of client behaviors that will guarantee security and achieve
   maximum interoperability during the transition period.  Clients need
   to choose one or the other preference when dealing with potentially
   un-upgraded servers.
Also client seems like by default due to this will not want to break the connection hence did not enforce secure reneg by default. Regardless, you need to enforce that then see these setting in the major browser related security settings...

Microsoft Schannel -
Mozilla -
Chrome -!topic/chrome/Lyb2ZZwynnM

Test out your browser with this ssllab link - it test for Secure Renegotiation (and more..) -
SSLLab server test -

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.