Poodle: Is disabling SSL V3 on server really a solution?

Question

I've been reading all day about the Poodle vulnerability and it I am bit confused now vs Security and Revenue.

If I disable SSL V3 on Server (SSL V2 and V3 both will be disabled for Apache) clients (browsers) who don't support any protocol but SSL V3 will not be able to connect HTTPS with the server.

So it's situation where both client and server must communicate with TLS 1.1 1.2 and so on

If any of them uses SSL V3 and the other does not support lower versions then what happens ? No connection to SSL.

I've seen few updates made to Firefox, perhaps they have disabled the SSL V3 in that what we usually have to do in options. This will force all the connection to lower versions and TLS

But is disabling SSL V3 really a solution for this problem ?

Answer 1

First, let's clear things up a bit:

• TLS superseded SSL. TLS 1.0 came after and is an update to SSL 3.0.

  TLS 1.2 > TLS 1.1 > TLS 1.0 > SSL 3.0 > SSL 2.0 > SSL 1.0

• SSL versions prior to 3.0 have had known severe security vulnerabilities for a while and are disabled/not supported by modern clients and servers. SSL 3.0 will likely go the same way soon.

• Of currently-used protocols, "Poodle" most severely affects SSL 3.0, where there is no way to mitigate. There is a similar attack against some TLS 1.0 and 1.1 implementations that the spec allows - make sure your software is up to date.

---

Now, the reason "Poodle" is a risk even with modern clients and servers is due to clients' implementation of a fallback mechanism. Not all servers will support the latest versions, so clients will try each version in order from most to least recent (TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0) until it finds one that the server supports. This happens before encrypted communication begins, so a man-in-the-middle (MITM) attacker is able to force the browser to fall back to an older version even if the server supports a higher one. This is known as a protocol downgrade attack.

Specifically, in the case of "Poodle", as long as both the client and server support SSL 3.0, a MITM attacker is able to force the use of this protocol.

So when you disable SSL 3.0, this has two effects:

• Clients that support higher versions cannot be tricked into falling back to the vulnerable version (TLS Fallback SCSV is a new proposed mechanism to prevent a protocol downgrade attack, but not all clients and servers support it yet). This is the reason you want to disable SSL 3.0. The vast majority of your clients likely fall into this category, and this is beneficial.

• Clients that do not support TLS at all (as others have mentioned, IE6 on XP is pretty much the only one still used for HTTPS) will not be able to connect through an encrypted connection at all. This is likely a minor portion of your userbase, and it's not worth sacrificing the security of the majority who are up-to-date to cater to this minority.

Answer 2

Your assessment is correct. Clients will need to use newer protocols to connect to your server once you disable SSL 3. The SSL 3 protocol is flawed, and there will be no "patch". Disabling SSL 3 is the only solution.

So many sites have disabled SSL 3, at this point, as to make it virtually inevitable that users of older browsers will need to upgrade. Assuming you're logging user agent strings you can review your logs and make an informed decision about disabling SSL 3. I think it's likely that only a small percentage of your site's visitors are using browsers that would be unable to handle the newer protocols.

[fwiw - cloudflare reports 1.12% of users are IE6 XP users depending on SSLv3]

Answer 3

Yes, Disabling SSL3 will make it so that users who don't support TLS cannot access your website.

However, from a practical standpoint, look at what browsers fall in that category. Chrome and Firefox both support TLS and are even going to drop SSL3 support entirely due to this bug. IE has supported it since IE7. The only browser that doesn't have support, but is still used on a global scale, is IE6, and the only reason that's still used is 2 reasons:

1. Anyone with a cracked version of XP and no way of using Chrome or Firefox;
2. Anyone on a corporate or government policy with restrictions regarding browser choice.

In both of these cases, IE6 is used because it's the default Windows XP browser that comes with the original install. In addition, the only reason that IE6 still has a (small) global market share is because of the many users in China.

So, long story short: here are 3 questions:

1. Do you have a significant Chinese userbase?
2. Does your website provide support for IE6, even though it's antiquated and broken?
3. Is your website a product used by a government or corporation with browser choice restrictions?

If any of these 3 are true, you'll have to find an alternate solution. If all 3 are false, just disable it and be done with it. And if you need the alternate solution, do you damn hardest to convince that small part of your userbase that still uses IE6 to switch away from a 13 year old browser.

Answer 4

You mention "Apache" and "browsers" in your question, but the title is more general.

As Evan and others point out, the problem is all-but-sorted for HTTPS. But there are a number of other protocols that a server might encrypt, and TLS support is much poorer amongst that client base (as I found out this morning, when mandating "no SSL3" on an IMAP/S server).

So I'm afraid the answer is "it depends on what services you encrypt, and the client support for TLS amongst your user base".

Edit: yes, that was my point, though I'm glad you agree. Turning off sslv3 is done on a service-by-service basis. For example, the way to turn it off on dovecot is to put

ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

in dovecot.conf. The bigger problem is that whilst most browsers are tolerant of the loss of sslv3, clients of other services seem to be a lot less tolerant. I broke about half my users this morning when I turned that off on dovecot; Android phones running K-9 mail and Outlook on Win7 are two that I know of for sure, but I can see from my logs there were more.

Turning off SSLv3 is still not only a valid solution, it is the only solution; but it's going to hurt.

Edit 2: thanks to dave_thompson_085 for pointing out that disabling SSLv3 ciphers in dovecot disables not the just the SSLv3 protocol, but TLSv1.0 and TLSv1.1 as well, since they have no ciphers that the earlier protocol doesn't. Dovecot (at least, earlier versions, which include the one I'm running) seems to lack the ability to configure protocols rather than ciphersuites. This probably explains why doing it broke so many clients.

Answer 5

Disabling SSLv3 is the best solution, but I don't agree it's the only solution. As CloudFlare describes, SSLv3 usage is very low, so most admins should have no problem turning it off.

If you have a speciel requirement for SSLv3, maybe you are required to support IE6 on Windows XP, or you are required to support very old software, there is another way of mitigating it.

The way to mitigate it, and keep SSLv3, is to use RC4 and support TLS Fallback SCSV, which is provided by OpenSSL 1.0.1j. In the qualys post on poodle, RC4 is the "certain insecure stream cipher whose name no one wants to mention".

This is what google does on mail.google.com, and they also describe it in they blog entry: http://googleonlinesecurity.blogspot.se/2014/10/this-poodle-bites-exploiting-ssl-30.html

Answer 6

One detail is missing from the conversation, based on the original question it may be a good idea to note it. TLS 1.0 is also referred to as SSL 3.1, so original poster, you should look at your config, are you running v3.0 or v3.1

Answer 7

As with most things, the answer is "it depends". The only browser in any sort of "common" usage that does not support TLS is IE6. Unfortunately, various reports say that IE6 may be as much as a few percent of global HTTP requests (see: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html). The good news, if your in North America, is that it's relatively uncommon in the US. To be safe, you should look at user agent statistic from your www logs. In my case, there were so few IE6 ua finger prints that I assumed they were all from testing tools.

You can test your website(s) with ssllab's tester to see how various agents react.

https://www.ssllabs.com/ssltest/

TL;DR - SSLv3 is dead; long live TLS.