3

Looking at thc-ssl-dos, it only affects SSL enabled web sites with renegotiations enabled.

I have been checking a few servers and have the following questions;

First; renegotiations are disabled by default on my Apache installations, so in what scenarios would I enable it?

Secondly; I have a dev box with a few vhosts on it, how can I enabled it (for the default site only) so I can test the effectiveness of this attack? I'm running apache2 on Debian squeeze.

Thank you.

Tom O'Connor
  • 27,480
  • 10
  • 73
  • 148
jwbensley
  • 4,202
  • 11
  • 58
  • 90

2 Answers2

3

SSL/TLS Renegotiations were enabled by default but many linux distros released patched versions of Apache that disabled renegotiations. You need to check the version number and changelog for your Apache distribution to be sure.

Assuming you are using a version that has renegotiations disabled, you can re-enable it by setting SSLInsecureRenegotiation on in your apache config.

mahnsc
  • 1,796
  • 13
  • 11
3

Apache 2.2.15 or greater running with OpenSSL 0.9.8l or lower disables client-initiated renegotiation completely, no way to turn it on.

With OpenSSL 0.9.8m in Apache 2.2.15 or greater, you have a couple things going on:

  • The new secure renegotiation standard from RFC 5746 is enabled by default.
  • The old renegotiation protocol is disabled by default, but can be re-enabled if desired for clients that don't support the new standard via the SSLInsecureRenegotiation On directive.

From the little digging that I've done on this issue, it's unclear to me whether the type of renegotiation in use (the new, "secure" kind or the old standard) has a bearing on whether the attack is successful - it may work just on one or the other, or on both.

As far as the scenarios that it needs to be enabled for, I believe that client certificate authentication is the main use case.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251