39

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 ?

MadHatter
  • 78,442
  • 20
  • 178
  • 229
sandeep.s85
  • 2,059
  • 1
  • 18
  • 26
  • 4
    What do you mean by "This will force all the connection to lower versions and TLS"? SSLv1 and SSLv2 have been disabled for a long time because they have been broken. SSLv3 has been frowned upon but in many cases remained enabled to support legacy software. What is the lower version you are referring to? TLSv1.0, v1.1, v1.2, ... are later standards and can be considered "higher version SSL", only the version numbers were reset with the name change. – Håkan Lindqvist Oct 17 '14 at 05:33
  • Hi, so what I have understood so far is If I disable SSL V3 and V2 on Server as recommended by Red Hat too, the secure connection will be on TLS protocol. And if the browsers are making a call on TLS with the server then there won't be an issue in secure connections.I don't have the exact information about the difference b/w SSL and TLS versions.. – sandeep.s85 Oct 17 '14 at 06:49

7 Answers7

52

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.

Community
  • 1
Bob
  • 1,536
  • 12
  • 17
  • 8
    Hi Bob, this is Alice here. Like your explanation about how Mallet can make use of Poodle. – BatteryBackupUnit Oct 17 '14 at 12:02
  • +1 Didn't know about the protocol downgrade attack. – developerwjk Oct 20 '14 at 20:39
  • 1
    UPDATE: `"...everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken, including many implementations which conform to current specifications."` http://www.zdnet.com/article/poodle-not-fixed-some-tls-systems-vulnerable/ – BlueCacti Dec 22 '14 at 09:14
  • @GroundZero *> But it turns out that some TLS implementations still didn't check the padding bytes, despite the ability to do so.* => specifically, while TLS 1.0 and 1.1 *implementations* may be broken (and the spec *allows* them to be broken in this fashion, which isn't good), it's not as bad as SSL 3.0 where *the spec itself* was broken and there was no way for a conforming implementation to work around it. Also, "turning off" TLS 1.0 and 1.1 support on the server is a much harder problem than turning off SSL 3.0 - you'll affect a far larger proportion of your users. – Bob Dec 22 '14 at 09:32
  • Seems like it's primarily the server-side implementations that are vulnerable (?) - fix your TLS implementation on the server, and you should be fine (?) [I haven't looked into this enough to confirm that browsers and other clients are unaffected, but the wording in your linked article and its source do suggest that]. – Bob Dec 22 '14 at 09:33
  • I like this explanation, very concise and to the point – Kat Lim Ruiz Feb 17 '15 at 14:42
  • re "spec allows": 1.0 rfc2246 doesn't explicitly say receiver must check padding, although it has long been taken as implicit in crypto, but 1.1 rfc4346 6.2.3.2 does (and so does 1.2 rfc5246). – dave_thompson_085 Apr 12 '15 at 18:37
27

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]

cnd
  • 220
  • 2
  • 5
Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • 1
    While it's true that SSLv3 is flawed, and the only *real* solution is to disable SSLv3. There is also a mitigation for the poodle attack that don't require disabling SSLv3, if you can accept the RC4 cipher for TLS 1.0 clients, since poodle only affects CBC mode ciphers (AES). I've described it here: http://serverfault.com/q/637848/249649 – cypres Oct 17 '14 at 16:45
  • 2
    `TLS_FALLBACK_SCSV` isn't mitigating the attack for older clients, though. It's just allowing older clients to continue to use the flawed protocol while preventing undesirable protocol version downgrades for newer clients. In the end, leaving SSLv3 enabled for any clients is potentially exposing their traffic to attackers. – Evan Anderson Oct 17 '14 at 17:00
  • RC4 is mitigating this attack for older clients, not scsv. But we rather not use RC4, which is why I also recommend disabling SSLv3 if at all possible. – cypres Oct 17 '14 at 17:31
  • 1
    @cypres - Yes-- 'TLS_FALLBACK_SCSV' doesn't help older clients. I'd argue that using a cipher that has been shown to have serious weaknesses isn't helpful either. We need to let this be a "flag day" that eliminates SSL 3.0 from the 'net. Sure-- if you've got older appliances, embedded devices, etc, that don't support TLS inside your enterprise then feel free to run SSL 3.0. I think it's irresponsible to encourage anyone to continue to use SSL 3.0 on the public Internet, though. – Evan Anderson Oct 17 '14 at 17:36
  • Today I disabled SSLv3 on Firefox and allowed only TLS and I see fair amount of ssl connection issues while browsing websites on internet. I am supporting hundreds of Linux servers where sslv3 is enabled. I may be wrong but the ultimate solutions to this situation is until OS vendors release a patch so that nothing should be done on client end. The problem is that you can not predict the impact. – sandeep.s85 Oct 21 '14 at 17:18
20

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.

Nzall
  • 331
  • 1
  • 8
7

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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • 1
    I have also now read that this will not only impact the web servers but any service running on the server that make use of SSL i.e. Web Servers, LDAP Servers, SSH daemons, POP3 servers, SMTP servers So for web servers we have Configuration in Apache mod_ssl config file as SSLProtocol All -SSLv2 -SSLv3 We need to look on other services as well on how do we prevent client/server to use SSLv3 – sandeep.s85 Oct 17 '14 at 12:24
  • The actual POODLE attack, as described in [the security advisory](https://www.openssl.org/~bodo/ssl-poodle.pdf), relies on a fair amount requests made with some ability of control from the attacker. In the context of HTTPS and browsers that is feasible thanks to scripting but in the context of eg IMAPS I'm not convinced that this is a practical thing to do. Getting rid of SSLv3 across the board is of course ideal but I'm just not sure that POODLE in particular is all that relevant to some of these other cases. – Håkan Lindqvist Oct 25 '14 at 10:30
  • Håkan, as time passes, I am more and more in agreement with you. – MadHatter Oct 25 '14 at 10:33
  • 3
    Disabling **ciphers** `!SSLv3` in openssl actually disables all protocols except TLSv1.2, which may not be good for your peers. This is why disabling the **protocol** is better, but AFAICS only in dovecot 2.1+. See http://security.stackexchange.com/questions/71872/disable-sslv3-in-dovecot-tls-handshaking-failed-no-shared-cipher . – dave_thompson_085 Nov 22 '14 at 10:39
  • @dave_thompson_085: when you say "*disabling... in openssl*", do you mean "*disabling ... in dovecot*"? If so, I agree with you, and I'll amend my answer in the light of this information, if you can clarify as requested. – MadHatter Nov 22 '14 at 13:20
  • I was a bit terse; I mean *openssl as called by dovecot*. openssl is a library with many options, some pretty complicated, including cipherstring settings. In this case you put the setting in dovecot which passes it to openssl, and it is openssl's ciphersuite categorization that causes this setting to produce the result that protocols below TLSv1.2 can't be negotiated. – dave_thompson_085 Nov 23 '14 at 03:36
6

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

cypres
  • 601
  • 4
  • 13
2

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

Cybersecchimesin
  • 21
  • 1
-3

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.

Joshua Hoblitt
  • 665
  • 4
  • 11
  • 15
    IE6 is not the last version compatible with XP, it's the version that XP shipped with. IE8 is the last version compatible with XP. – Håkan Lindqvist Oct 17 '14 at 05:12
  • 6
    -1 due to factal incorrectness indicating IE6 is the latest version on xp. – TomTom Oct 17 '14 at 05:17
  • `may be as much as a few percent of global HTTP requests`. I'd like a source for that. CloudFlare says this about usage: `In other words, even on an out-of-date operating system, 98.88% Windows XP users connected using TLSv1.0+` (https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/). Which is far far less than "a few percent" globally. – faker Oct 17 '14 at 16:55
  • 1
    I suspect cloudflares customers are mostly large north american companies. The stat I quoted came from netcraft: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html "Despite its age and the end of Microsoft's support for Windows XP, IE6 remains popular, accounting for more 3.8% of web visits worldwide, and 12.5% in China. This vulnerability may ring the death knell for IE6 and Windows XP." – Joshua Hoblitt Oct 24 '14 at 17:10