Subscribe
The internet has been in an uproar over the past few days as a result of Google’s announcement of the POODLE vulnerability, which effectively breaks SSLv3 completely. We’ve scanned every single site that has passed verification with Tinfoil Security (that is, signed up and verified ownership) using our testing tool, and sent emails to all those customers that have vulnerable sites. Our anonymized statistics of websites that have been tested show that 68%—that is, more than two-thirds—of the internet is vulnerable as I write this.
There has been a lot of misinformation flying around the internet over the past few days, and a lot of overly technical (or not technical enough) “how to” guides that are actually incorrect. This isn’t because the internet intends to mislead, but simply because cryptography of any sort, but especially TLS/SSL, is hard. We don’t claim to be experts, but we try really hard to be well-versed. With that in mind, this is our guide on how to protect your servers and what mistakes you’ve probably (unintentionally) made.
How Everyone Is Messing Up Cipher Disabling
The simplest thing to think is “OK, so it looks like if I disable any cipher suite that has CBC in the name, I’ll be fine.” This is wrong, and everyone is doing it, because it is what everyone is recommending.
There are a number of cipher suites, specifically AES128-SHA, AES256-SHA, and similar, that do not contain CBC in the OpenSSL cipher suite name. In reality, these cipher suites are named TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA, respectively. These cipher suites do work in CBC mode, no matter what OpenSSL chooses to call them!
We’ve disclosed this exact vulnerability to many companies at this point, including some large, extremely engineering-focused companies I guarantee you’ve heard of, all of whom have mitigated it now by disabling these last few ciphers. Given that we continue to see this exact mistake across most of the websites we’re testing, you should make sure you check it on yours too.
Your best option
Disable SSLv3 completely. Do not support it as a protocol at all, and reject any clients which require it. Unfortunately, this proves hard to do for many companies, as they have legacy clients whom they need to support that only support SSLv3 (specifically, IE6 on Windows XP and older Android clients, usually).
Our recommendation is simple: if, in any way, you can completely disable support for older clients that require SSLv3 and disable support for that protocol entirely, please do it.
Your next best option
If you must maintain support for SSLv3, your next best option is to enable the TLS_FALLBACK_SCSV cipher suite value. This cipher is a patch submitted to OpenSSL by Google (the same team who found the exploit in the first place). This cipher solves the issue of retrying failed connections, thus preventing attackers from forcing browsers to use SSLv3. Additionally, it may also help prevent future exploits, as it prevents downgrading from TLS 1.2 to 1.1 or 1.0 as well.
Our recommendation: Make sure that you support the TLS_FALLBACK_SCSV cipher suite value. If you use OpenSSL 1.0.1, make sure you upgrade to 1.0.1j. Similarly, if you use 1.0.0, make sure to upgrade to 1.0.0o, and if you use OpenSSL 0.9.8, upgrade to 0.9.8zc.
Your last resort
If you cannot disable SSLv3, and if you cannot upgrade OpenSSL to support TLS_FALLBACK_SCSV for some reason, you have one additional option left: carefully disable all cipher suites for SSLv3 that run in CBC (cipher-block chaining) mode. Really, you should do this anyway, since TLS_FALLBACK_SCSV doesn’t actually resolve POODLE for anybody using SSLv3, it just prevents any newer clients from downgrading to SSLv3 and thus becoming vulnerable, limiting the number of clients that are affected.
This means that if you have to use SSLv3, your only real option left is to use some form of an RC4 cipher. This also isn’t perfect (there is a known attack on it by way of Royal Holloway, but it requires 224 connections), but is better than using any of these CBC ciphers which can be broken much faster.
If your configuration doesn’t allow you to disable these CBC ciphers only for SSLv3 (for example, if you run nginx), you should consider using something like HAProxy to terminate SSL traffic in front of it and disabling / redirecting around it there. This, however, is hard and prone to error so you can go with the next recommended option: make sure your preferred cipher is set to RC4, rather than any CBC cipher
Our recommendation: The following cipher suites that SSLv3 is able to use must be disabled in order to effectively prevent POODLE:
Check, and check again.
We’ve been updating our tester constantly and improving its detection and results. We’ve added even more information regarding supported ciphers and the like. When you think you’ve fixed your server against POODLE, you should run another check.
We will continue to keep our eyes on this and attempt to update this post with more ways companies are making common mistakes in mitigating this attack, but if you follow the above directions, you should be OK. Scan yourself for even more vulnerabilities using the button below.
Feel free to contact us at any time.
Continue Reading
Introducing fAST Dynamic: Streamlining dynamic application security testing
Mar 19, 2024 / 3 min read
