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.

http://thehackerschoice.wordpress.com/2011/10/24/thc-ssl-dos/

http://www.thc.org/thc-ssl-dos/

===============

Rob VandenBrink
Metafore