The Theoretical "SSL Renegotiation" Issue gets a Whole Lot More Real !

Published: 2011-10-26
Last Updated: 2011-10-26 14:02:09 UTC
by Rob VandenBrink (Version: 1)
6 comment(s)

For years, we have been taught (warned?) that establishing an SSL session consumes much more in the way of CPU resources than the actual sessions do, once established. We've also been warned that there is a theoretical vulnerability in SSL Renegotiation in many web server implementations.  Combined, they make for a nice "it'd be bad if someone wrote such a tool" story in many security classes.

These two situations are evident in the specifications for SSL offload and Load Balancer devices, which are typically rated in "sessions established per second" rather than a total session count or data throughput value. It's also very much "in our face" when doing vulnerability assessments, when web server after web server comes back with a vulnerability named something like "SSL Renegotiation saturation" (or similar).   We've been told, over and over, that there is a "theoretical" problem here, waiting for an exploit to happen.

Since there hasn't been much in the way of exploits in this area, efforts towards resolving the SSL Renegotiation problem haven't been on anyone's front burner. That's all changed now - THC (The Hackers Choice), has released another tool - THC-SSL-DOS. This tool targets the problem of SSL Renegotiation. With very limited bandwidth, a single host can DOS almost any vulnerable web server.  Even offload devices such as load balancers are vulnerable (though more attacking hosts are required). In their release notes, THC makes the excellent point that the SSL renegotiation feature has never been widely used, and arguably should be simply disabled on almost all webservers.

Unfortunately, SSL Renegotiation is enabled by default on many servers, and we all know what happens with defaults - systems get installed with default settings, then NEVER get changed.

Just to emphasise the point, THIS IS NOT A NEW SECURITY EXPOSURE, it's simply a handy proof of concept tool to demonstrate a problem that's been hanging around for quite some time, hopefully with the goal (and with luck, the result) of getting this setting changed on vulnerable systems. 

Take a peek at this new tool.  Hopefully it will serve as a catalyst, proving that this is one setting that should be changed post-install.  It'd be nice if the developers of affected web server applications would take this as a cue to modify their installation scripts to change the default value of this setting as well.


Rob VandenBrink

Keywords: Renegotiation SSL THC
6 comment(s)


Correct me if I'm wrong, but at least Nginx doesn't seem to be too vulnerable to this kind of attack, as renegotiation is disabled as soon as the initial handshake is complete. One ends up in the same situation as if the server didn't support renegotiation at all.

I had to tweak the source somewhat to make it play nice with a TLS-only setup and end up with the message:

Handshakes 0 [0.00 h/s], 1 Conn, 0 Err
ERROR: Target has disabled renegotiations.
Heh...I tested this today attacking a Nesus web server on the same one core to hit 100% for a few minutes, then backed down to 80%. Kinda boring really...didn't seem to be a big deal even with setting the connection attempts to 1000
I took the code from THC and modified it slightly just to check for the vulnerability using their logic and acting as 1 peer. That way you don't actually have to crash your site to check it. The code is pasted at
I wasn’t able to get it to completely “knock a server offline.” It causes the CPU to spike and the server to slow down substantially but it never becomes completely unreachable. But then again, this is in my lab.

The code Ispells posted works very well in checking to see if a host is vulnerable and makes scripting a check on hundreds of hosts a breeze, thank you.
Darkfiber, Thanks for the nice comment. One thought... THC's original cipher list played nice.

Try setting your cipher list to something like the following in the source (should be around line 730 in the init_vars function).


This should give priority to the ciphers that use triple DES and the Ephemeral Diffie-Hellman algorithms, etc., assuming the server you are connecting to supports them. These should be more computationally intensive.

I'd love to know if you see benefit in this.
I found the attack can be completely nullified with a simple firewall rule.

Diary Archives