Qualys Blog

Ivan Ristic

SSL 3 is dead, killed by the POODLE attack

The POODLE Attack (CVE-2014-3566)

Update (8 Dec 2014): Some TLS implementations are also vulnerable to the POODLE attack. More information in this follow-up blog post.

After more than a week of persistent rumours, yesterday (Oct 14) we finally learned about the new SSL 3 vulnerability everyone was afraid of. The so-called POODLE attack is a problem in the CBC encryption scheme as implemented in the SSL 3 protocol. (Other protocols are not vulnerable because this area had been strengthened in TLS 1.0.) Conceptually, the vulnerability is very similar to the 2011 BEAST exploit. In order to successfully exploit POODLE the attacker must be able to inject malicious JavaScript into the victim’s browser and also be able to observe and manipulate encrypted network traffic on the wire. As far as MITM attacks go, this one is complicated, but easier to execute than BEAST because it doesn’t require any special browser plugins. If you care to learn the details, you can find them in the short paper or in Adam Langley’s blog post.

SSL Labs Changes

We made three improvements to the SSL Labs web site to properly test and warn about the POODLE attack: 1) warnings about SSL 3 support and vulnerability to POODLE, 2) test for TLS_FALLBACK_SCSV and 3) new client test that detects support for SSL 3. At this time, a server vulnerable to the POODLE attack will be given a C grade, but we’re likely to change this grading in the near future, after we carefully consider all our options.

What Now?

POODLE is a protocol-level vulnerability that can’t be easily fixed. Although it might be possible to attempt a BEAST-style mitigation, it seems that browser vendors are not interested in that approach. Adam said Chrome won’t pursue that direction. Firefox said they would disable SSL 3 in Firefox 34. And that’s great news. Traditionally we struggle with letting go of old protocols. Because SSL 3 is not very widely used and POODLE is serious enough, it seems that we’ll be able to retire this old protocol version soon. In fact, some CDNs have already disabled it.

What You Should do

You can look at this problem from two perspectives. As a user, you want to protect yourself from attacks, and the best way to do that is to disable SSL 3 in your browser. (Instructions are easy to find online.) The updated SSL Labs Client Test will tell you if your change was successful.

As a web site operator, you should disable SSL 3 on your servers as soon as possible. You need to do this even if you support the most recent TLS version because an active MITM attacker can force browsers to downgrade their connections all the way down to SSL 3, which can then be exploited. In normal operation, SSL 3 shouldn’t needed by the vast majority of sites. Although it’s likely that there’s a long tail of clients that don’t support anything better, Internet Explorer 6 on Windows XP is potentially the biggest user segment that still relies on SSL 3. Options are to guide users to manually enable TLS 1.0 (IE6 supports it, but not by default) or upgrade to other browsers. In the short term, it’s possible to mitigate POODLE by avoiding using CBC suites with SSL 3, but that involves relying on a certain insecure stream cipher whose name no one wants to mention. I don’t recommend this approach.

POODLE wouldn’t be as serious without the ability of the active network attacker to downgrade modern browsers down to SSL 3. There’s a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective. Google implemented this feature in February (in Chrome and in their web sites) and has been successfully using since. Mozilla said Firefox will support the indicator in early 2015. A new version of OpenSSL has just been released, which includes support for the SCSV. The support might be backported to various Linux distributions. For best results, support also needs to be added to other major browsers. Once that happens, the POODLE attack surface will be much smaller; it will affect only the users with older browsers.

For detailed guidance on how to disable SSL 3 in various servers and browsers, head to Scott Helme’s blog post. Qualys customers should go here to learn how to configure reports to find systems that use SSL 3.

19 responses to “SSL 3 is dead, killed by the POODLE attack”

  1. What’s your suggestion for sites that don’t have the luxury of blocking IE6 users?  I think they account for about 3% of the world? [cloudflare says 1.12% of their traffic] – either way – that’s at least 1 in every 100 customers who’s going to hit support desks with outage-fury; for businesses with millions of users – that’s dire.

    If CBC is disabled, what gets used instead, and why is it insecure?

    • If CBC is disabled then you’re left with RC4, which is also insecure. The preferred approach to addressing POODLE is to disable SSL 3, which is why no one is mentioning RC4 by name. The problem is that, from what is publicly known at the moment, the exploit against RC4 isn’t exactly practical. From that perspective, RC4 is lesser evil than CBC with SSL 3. (As much as I hate to say it.) But, there’s a caveat: it’s generally assumed that the RC4 problems are worse than currently demonstrated and that it can be used in a practical attack.

      Those who don’t disable SSL 3 straight away should immediately put a page for all their SSL 3-only customers to attempt a smooth transition to a better browser on Windows XP (i.e., Chrome or Firefox). It’s also possible to show instructions how to enable TLS 1.0 in IE6, but upgrading the browser is a _much_ better option.

      • Thanks for that detail!  In case others are reading this – my requirement to support IE6 users almost certainly is different to you – my server provides out-of-band anti-malware and anti-phishing protection – yeah, it’s bad to decrease security, but in my unique case, it’s mitigated by the purpose.  If you don’t have a mitigation in place for the possible reduction to security of all 100% of your users, don’t follow me in my quest to look after those 1.12% of outliers!

  2. I think this Poodle is bogus.  The SSL3 MAC is based on the blocksize of the hash – not on the length of the plaintext.  The attack seems to mistakenly think that the random padding is not part of the hash, but it is?

    • No, the padding isn’t part of the MAC/hash. SSL and TLS use MAC-then-encrypt, where the the plaintext, MAC (of the plaintext only), and padding are combined and encrypted. The MAC is documented in the section of RFC 6101.

      With RFC 7366 this can be changed to encrypt-then-MAC, but this addition is both brand new and it’s not supported with SSL 3.

      • RFC6101 (year 2011) seems a bit too recent for a 1995 protocol? All the same – in the CBC section – it does document what I’m talking about:  "padding: Padding that is added to force the length of the plaintext to be a multiple of the block cipher’s block length."

        They mess with plaintext length (because the padding size is indicated separately) – so there is never a situation I can see where you can merely change some bits of the last packet and hope to decrypt one byte – every bit of that last packet was part of the MAC already.

        Even if I’m wrong – and getting 8 bits from 256 guesses actually worked, I also don’t see how this helps, you can’t get another 8 bits from 256 more guesses – to get the last *2* bytes of a cookie, you’ll need 65536 guesses,or 4 billion guesses for 4 bytes ?  Just because (say) the first 7 out of 8 bytes are unchecked random, doesn’t mean that every bit that makes up that last plaintext byte lives in that encrypted position – the encryption mixes it all around.

        But, that’s a distraction – as far as I can see – the padding becomes part of the plaintext, and is included in the mac. Yeah, it’s later discarded, except you won’t get past the mac problem if the padding is wrong, and the padding is supposed to be random (says so in the 2011 spec – and you’d expect everyone in the past who coded this would know and did that, even if it wasn’t documented back then)

  3. The SSL Server Test on this site doesn’t account for SSL 3.0 connections redirected to a public information page.  Are you able to adjust your ratings based on this info?

  4. "POODLE wouldn’t be as serious without the ability of the active network attacker to downgrade modern browsers down to SSL 3. There’s a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective."

    How would this actually work? Would this keep the encrypted data stream at the TLS protocol in an SSLv3 enabled environment? And what exactly do you mean by "wouldn’t be as serious". Can you explain how using TLS_FALLBACK could still vulnerable? What are the limitations here?

    • user5309,

      With SSL 3 enabled and TLS_FALLBACK_SCSV supported, your SSL 3-only users are still vulnerable. Also vulnerable are all users whose browsers don’t support TLS_FALLBACK_SCSV. At this point only Chrome supports it, and Firefox said they would in early 2015.

      • A related question. I could be wrong, but I also understood that not all browsers actually allow downgrading of the connection in the first place. So some may not be vunerable to downgrade attacks. I understood IE and Opera are in fact not, and hence for those it may not matter if they don’t support TLS_FALLBACK_SCSV.

        See e.g. Man-in-the-Middle TLS Protocol Downgrade Attack (dated from before POODLE). But I’ve seen this reported before on other sites.

        (Note I’m not saying there is no issue, and would also recommend getting rid of SSL 3.0, but this would still reduce the attack surface.)

  5. Thanks for all those useful info you guys sharing. I’ve being using them a lot since years.

    1. I know some enterprise webapps are still struggling with IE6 legacy users. So I wonder if they can do a bit more and I can’t figure this answer with Google… Some SSLLabs server scan reports show "POODLE attack: No, mitigated", even when SSLv3 is enabled and TLS_FALLBACK_SCSV not supported! What kind of mitigation are your tools referring to? Server side? I though POODLE was a pure client-side issue?
    2. Sorry if this is not the place to do it, but I’d like to share a bit myself on this topic. I had some trouble disabling SSLv3 with some software (OpenLDAP from EPEL, which appears to be compiled with MozNSS and no obvious protocol switches). So I though about a previous attempt of mitigating Heartbleed via iptables using u32 module… And here is what works for me when it come to reject SSLv3 connections when the application can not be configure:

    iptables -A INPUT -p tcp -m state –state RELATED,ESTABLISHED -m tcp –dport 636 -m u32 –u32 "0x33&0xFFFF=0x0300" -j LOG –log-prefix "REJECTED – SSLv3 "

    REM: I could not find this trick anywhere. Maybe because it is pointless?

  6. To disable SSLv3 on Ubuntu, here is what you do:

    sudo vi /etc/apache2/mods-available/ssl.conf

    Find the line “SSLProtocol all” and change it to “SSLProtocol all -SSLv3” (add “-SSLv3” to end of the line)

    sudo service apache2 restart

    This will remove the POODLE vulnrability. Hope this saves someone time.

  7. Hello,
    Isn’t Poodle occuring on SSLv3 with CBC ciphers only or am I reading all the documents on the web wrong ? Please clarify.

    Granted SSLv3 is insecure but there are legacy devices and OSes running out there, so if a server have SSLv3 enable but no CBC ciphers or weak RC4 128 bit cipher, shouldn’t ssllabs test result not flag server is vulnerable to the POODLE attack?

    Even Oracle is still allowing a way for customer on Java6 to run SSLv3 along with TLS if necessary , by removing SSLv3 from jdk.tls.disabledAlgorithms

    • Yes, POODLE does only affect CBC suites. Given that all RC4 is broken, we can’t in good conscience recommend anyone to use it. The only appropriate approach is to disable SSLv3 as soon as possible.

Leave a Reply