How to defend against SSL-Exhaustion attacks?

Question

The problem of SSL-Exhaustion attacks is well known for years, but nobody really cared until THC released their exploit-tool recently. THC talks about counter measurements in their release:

No real solutions exists. The following steps can mitigate (but not solve) the problem:

1. Disable SSL-Renegotiation

2. Invest into SSL Accelerator

Either of these countermeasures can be circumventing by modifying THC-SSL-DOS. A better solution is desirable. Somebody should fix this.

Idea 1 simply doesn't work because the core of the problem is not based on SSL-Renegotiation. I am not sure about idea 2, SSL Accelerators. How many dedicated systems for SSL Acceleration would you need to prevent a big SSL-Exhaustion attack? Does this make sense for an average SSL-Server?

So what I am asking here is, what can we do to prevent such attacks until a solution to the core problem is available? How can we protect our servers that rely on encryption?

Answer 1

"SSL exhaustion" is a mean looking expression for a more generic attack known as "not playing nice". In broad terms, it goes like this: a server is offering a network service, which, on the server, is not free: when a client comes, the server must invest some of its precious CPU cycles into responding to that client. The "attacker" is then someone who mimics many needy clients, overburdening the server. In the case of SSL, the investment is substantial because of the involved cryptography; but the concept also works when the server effort is the meagre amount of CPU and RAM needed to simply establish a TCP connection (that's called SYN flood, but, from a high level point of view, this is the same thing).

A possible countermeasure (not possible in the case of SSL as it is, but it could be added as part of a modification of the protocol) is to require a "proof of work" from the client. In SSL, it is easy to mimic the initial steps of a client connection without doing any of the hard cryptographic work (simply send random junk instead of the expected RSA-encrypted pre-master key, or the client Diffie-Hellman public key): this is what should be changed. There are some pointers on the Wikipedia page on that subject.

For SSL as currently specified and deployed, you have no choice but to:

• try to identify offenders early enough, e.g. too many repeated connection requests from the same IP (this means that you block DoS which is not DDoS -- in simple words, the attacker will need to hire underlings / zombies);
• select cipher suites which are "cheap" for the server (don't use oversized keys ! 1536 bits are enough)(try RSA instead of DHE_RSA);
• counter the attacker by putting more muscle in it, e.g. hardware accelerators, or more PC (PC may be cheaper, but use more hosting space, and load balancing requires some additional system administration).

Answer 2

I think you missed the point, THC's tool isn't about exploiting systems. Its more about testing your own systems to make sure you are safe. If you are concerned, the very first thing you should do, is run THC-SSL-DOS against your own system to see how sustainable you are to attack. SSL isn't broken, its still the best thing we have.

Ways to mitigate this attack is to use a light weight cipher suite. And as you pointed out Cisco reccomends using an SSL hardware accelerator($$$) and disabling ssl's "secure renegotiation".