Mitigating sslsqueeze and other no-crypto, brute force SSL handshake attacks

I’ve spent a bunch of cycles lately trying to analyze how resistant we are to a new class of SSL handshake attacks. You see, I have a thing for these weird, asymmetric crypto attacks. To this day, the SSL Renegotiation DDoS piece is still the most popular article of mine, partly because the ~~obsessiveness~~ passion comes through in the writing.

The Classic SSL Renegotiation Attack

The original SSL renegotiation attack tool, by the French group “The Hacker’s Choice”, repeatedly requested SSL handshakes with a vulnerable server. These handshakes were ten times more CPU-intensive for the server than they were for the attack client. The BIG-IP SSL stack has become increasingly resistant to the tool; the latest versions of BIG-IP automatically reject clients that attempt to send multiple renegotiations in a single connection (no iRule needed).

A new class of handshake attack tools

There’s a new class of SSL attacks tools - one could call them “No Crypto” attack tools. These new attack tools boost the computational asymmetry between the client and the server to a 2^nd order multiplier by vastly reducing the client workload. Basically, the new attack clients don’t do any crypto at all – they just send pre-canned packets that look like an SSL handshake but aren’t.

In his excellent analysis of handshake attacks, Vincent Bernat writes about these much more efficient attack tools.

“With such a tool and 2048bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed on [in his analysis] may just be ineffective.”

One of these tools is called sslsqueeze and is written by none other than Michal Trojnar, the author of stunnel (the original SSL tunnel utility). Thankfully the tool isn’t widely available, but I was able to get a copy of the source. The sslsqueeze code is super tight. It is structured in such a way as to be almost entirely I/O-bound, so it is extremely lean with regard to the CPU.

Here it is throwing over a thousand handshakes a second against an Apache server using about 2% of the client CPU.

Each "success" means that the Apache server went to all the trouble to try to decrypt a bunch of junk and then returned "bad-record-mac" each time. Frankly, I'm impressed that an Apache server can turn around that many 2048-bit decrypts without hardware offload. That's what four cores will get you; each one doing about 300 decrypts per second (and little else).

After letting it run for a minute, the time command shows that sslsqueeze is nearly entirely I/O-bound. Not CPU-bound, which is what we expect since it's not doing any real crypto.

    sslsqueeze
    real 1m3.514s
    user 0m4.264s
    sys 0m7.904s

This is a single client, using almost none of its own CPU, keeping all four cores on a web server busy.

Can sslsqueeze overwhelm cryptographic accelerators?

Next I ran sslsqueeze against a real, physical BIG-IP with cryptographic offload accelerators.

I keep a BIG-IP 3900 at my house for just these kinds of cases where we need to see how the underlying Cavium cryptographic accelerators respond. This platform does not represent state-of-the-art hardware, but the BIG-IP 3900 remains one of the most widely-deployed F5 appliance models to-date.

See all those failures? That's because BIG-IP is returning record-overflow instead of bad-record-mac which is what sslsqueeze is expecting. The effect is really the same though. The 3900's crypto card is only rated for about 3000 SSL TPS (with 2K keys). The sslsqueeze program (on a single client!) is basically consuming all of that capacity without even really trying.

The modern equivalent of the 3900 is the 4200v, which is rated for 9000 TPS. The attack client computer that I bought for $200 at a used computer store can generate upwards of 20,000 (!!!) fake handshakes per second.

That’s not good. Not good at all. If even cryptographic processors can’t absorb the attack, how can you stop sslsqueeze?

Disabling SSL Renegotiation doesn’t help

During the original SSL renegotiation attack analysis, simply disabling renegotiation was sufficient to foil that attack. In fact, most servers were disabling renegotiation at the time to avoid a completely different vulnerability.

However, disabling renegotiation has no effect in this case. The sslsqueeze tool is so efficient that it doesn’t need to multiplex SSL handshakes through a single TCP connection. It simply opens a new TCP connection, sends its junk, waits for a response and then closes the connection.

iRules to the rescue once again

If disabling renegotiation doesn’t work and cipher selection doesn’t help and virtual server rate-limits don’t apply, what is left?

After exhausting all the options available in the BIG-IP 11.5 native SSL implementation, and still unable to effectively mitigate sslsqueeze, I turned to iRules. As a colleague of mine likes to say, iRules make the difficult tasks easy and the impossible tasks merely difficult.

In other words, when all else fails, you can always write an iRule.

iRule #1 – ssl_hx_rlimit

Here’s an iRule I had some fun putting together – ssl_hx_rlimit (SSL handshake rate limit). It’s a nice, clean iRule that has the following benefits:

Very small chance of false positives.
Minimal performance degradation (not measurable in my setup).
Minimal memory requirements (just one state variable per client address).
Not signature based – should catch all kinds of handshake monkey business.

Probably the biggest issue with this iRule will involve so-called mega-proxies or giant NATs where thousands of individual clients appear to come from the same IP (think AOL or other service provider). If an attacker is hiding behind one of these mega-proxies, then iRule #2 (see below) will have to be used instead.

The full iRule and it’s commentary can be found on this DevCentral page:ssl_hx_rlimit iRule

iRule #2 – sslsqueeze_rx

As stated above, the ssl_hx_rlimit iRule won’t really work if the attacker is mixing their bogus requests in with other valid requests from the same mega-proxy.There may also be other pathological cases as well where the ssl_hx_rlimit fails and you just need a quick fix to throw in place. iRule #2, sslsqueeze_rx, is that quick fix.

It has these benefits:

Extremely fast.
No additional memory requirements.
Can handle the mega-proxy cases

But also this main drawback:

Very easy for an attacker to change the attack signature.

sslsqueeze_rx works because the sslsqueeze tool sends the exact same ClientHello every time.

Therefore, all a signature-based system has to do is look for this incoming packet and block the connection.

If the attacker changes the ClientHello at all then you’d have to modify the static::sxch to represent the new signature. A determined attacker would be including random data in the 32 bytes of random data anyway. You could still key off the three specific ciphers that sslsqueeze is sending if you needed to.

The full iRule and it’s commentary can be found on this DevCentral page:sslsqueeze_rx iRule

Long Term Fixes in TLS?

The IETF TLS working group has taken a look at this problem recently and there is a proposal for a much more elegant fix than dropping or rate limiting. Enter “Client Puzzles”. There is a proposed draft for to ask the client to perform some kind of crypto puzzle to prove that it is a real TLS client and not some hack tool. It reduces the asymmetry by putting an arbitrary load on the client.

When I had told a colleague about this problem he said “instead of puzzle, could you have the client perform some Bitcoin block chain verification instead?” We discussed this option at the TLS meeting, but decided that it would lead to too much “gaming” on behalf of malicious servers, heheh.

http://tools.ietf.org/html/draft-nir-tls-puzzles-00

The puzzles would very likely be based on this trick.

· Server chooses a random number.

· Computes SHA hash for it.

· Asks client “which number, in this range, hashes to this value?”

You can increase the work done by the client by simply increasing the size of the range hint (keyspace). Making it “stateless” like a SYN cookie is a little trickier but could be done.

The client puzzle solution remains an interesting idea at this point with no real plans to be included in the handshake for TLS 1.3.

Another possible mitigator is the fact that the TLS protocol is slowly switching toward elliptic-curve key exchanges that are more balanced in terms of client versus server CPU load. This proposal is before the IETF committee right now for TLS 1.3. It is my hope that this will reduce the threat scope for these so-called “no crypto” attacks.

Conclusion

As I write this, attackers are still attacking the applications rather than the TLS servers themselves. Typically the attackers will find a large PDF file or an expensive database query and then they’ll just open TLS connections and request those URIs repeatedly. We stop those attacks with the web application firewall.

Internet Engineering Task Force drops RSA from next SSL standard (TLS 1.3) http://t.co/BCw64n4yFY via @kennwhite < wow! @rmhrisk
— David Holmes (@dholmesf5) May 4, 2014

As more web application firewalls get deployed and caching gets better and better, the attackers may start switching to TLS protocol attacks. Until TLS 1.3 gets adopted broadly supported you may find your SSL site under assault from one of these new attack tools. And if that happens, hopefully you’ll be able to defend your application with one of these two iRules. Let me know if you see an attack, or if you see ways to improve upon these iRules.

Published May 19, 2014

Version 1.0