927045 - upcoming SSL/TLS guidelines should prefer 3DES to RC4

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: General, defect)

Description

[zookog]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911163500

Steps to reproduce:

1. Have someone recommend https://wiki.mozilla.org/Security/Server_Side_TLS to me on an issue tracker: http://twistedmatrix.com/trac/ticket/6663#comment:31

2. Read https://wiki.mozilla.org/Security/Server_Side_TLS


Actual results:

I was advised to enable RC4 in my TLS config.


Expected results:

I should have been advised to enable 3DES in my TLS config.

There may be confusion because 3DES is related to DES, and DES is completely insecure (due to its small key size). As far as I know there is no reason to avoid 3DES. It is one of the best-studied ciphers in all of history (along with AES), and there is no known weakness in it. In contrast RC4 is weak, and recent discoveries have revealed that it is weaker than previously believed.

I configured my web site (https://zooko.com) to use Mozilla's recommend string (ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK) and then configured it to use my own string (ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-ECDSA-AES128-SHA:DES-CBC3-SHA), and asked ssllabs to evaluate it both ways.

According to ssllabs's simulation of popular TLS clients, both of these configurations would result in the same cipher suite being negotiated for all clients except for IE8/XP. For IE8/XP, the Mozilla string would result in:

TLS 1.0         TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS  128

And my string would result in:

TLS 1.0         TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   No FS     168

For all of the other clients simulated by ssllabs, the results were the same for these two strings, namely:

Chrome 30 / Win 7 	TLS 1.2 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 	128
Firefox 10.0.12 ESR / Win 7 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
Firefox 17.0.7 ESR / Win 7 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
Firefox 21 / Fedora 19 	TLS 1.0 	TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   FS 	128
Firefox 24 / Win 7 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
IE 6 / XP   No FS *		Fail**
IE 7 / Vista 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
IE 8-10 / Win 7 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
IE 11 / Win 8.1 	TLS 1.2 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 	128
Java 6u45 	TLS 1.0 	TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   FS 	128
Java 7u25 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
OpenSSL 0.9.8y 	TLS 1.0 	TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   FS 	128
OpenSSL 1.0.1e 	TLS 1.2 	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 	128
Opera 12.15 / Win 7 	TLS 1.0 	TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   FS 	128
Opera 16 / Win 7 	TLS 1.1 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
Safari 5.1.9 / OS X 10.6.8 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
Safari 6 / iOS 6.0.1 	TLS 1.2 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 	128
Safari 6.0.4 / OS X 10.8.4 	TLS 1.0 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 	128
Safari 7 / OS X 10.9 	TLS 1.2 	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 	128 







See also this ticket on the Twisted Python issue tracker:  http://twistedmatrix.com/trac/ticket/6663#comment:33

Comment 1

[Eric Shepherd [:sheppy]]

Not sure whose this is, but it's not something I know about. :)

Comment 2

[Julien Vehent]

The problem is that Internet Explorer on Windows XP doesn't support AES. That's why you end up with RC4.

Between RC4 and 3DES, I'm not sure which one is the most dangerous. I certainly don't want either, but at least RC4 has the benefit of being fast, while 3DES is definitely not.

Unless someone can show that 3DES is so much more secure than RC4 that it's worth the slowness, I'm marking this as WONTFIX.

Comment 3

[zookog]

RC4 is dangerous. Here's a blog post about that which links to further sources: https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what .

If Mozilla is going to recommend a known-dangerous cipher (RC4) in preference to 3DES, then the onus is on Mozilla to argue that 3DES is unsafe, not on me to argue that 3DES is safe.

(I *can* argue that 3DES is safe, and would be happy to do so, but I want you to go first, because RC4 is definitely unsafe, and I am aware of no reason to believe that 3DES is unsafe.)

If the motivation is to trade-off safety in order to gain performance, I could understand that, but please then state explicitly on the page that this trade-off is why you made this recommendation.

I'm going to change the status from "WONTFIX" to "UNCONFIRMED". I hope that is an appropriate thing to do here and is not offensive.

Comment 4

[Julien Vehent]

I renamed the title of this bug. Mozilla *does not* recommend RC4. RC4-SHA is in 25th position in the preference list, while 3DES isn't in the list at all.

Just to put things in perspective, we are talking about 2% of internet users who are still on Windows XP with IE6/7/8.

So far, the attack on RC4 target only the first 256 bytes of a session, and require large amount of traffic to perform statistical analysis on it. This isn't a practical attack, and that's why RC4 is still somewhere in the ciphersuite.
The article you point to even states that "there is practically nothing 100% secure they can use to replace RC4".

But, at the same time, we pushed RC4 so far down the list that only a minimal amount of clients still negotiate it. Replacing it with 3DES would only impact those clients. If/When the community decides that RC4 is sufficiently broken to remove it entirely, we can consider replacing it with 3DES.

Comment 5

[zookog]

> The article you point to even states that "there is practically nothing 100% secure they can use to replace RC4".

That is obsolete. At the time that article was written, CBC mode was dangerous, but that has been mitigated by client-side fixes on most (but not all) clients:

https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat

In any case, that is a weakness of CBC mode, not of 3DES, and effects AES-CBC exactly as much as it effects 3DES-CBC. In fact, turning off 3DES-CBC in order to protect against BEAST attack has absolutely no effect, since the attacker can always use AES-CBC instead. (Unless you also turned off AES-CBC, which nobody does.)

Let me try to summarize the facts:

1. The crypto community, at least as represented by myself, Ivan Ristic (https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat), Matt Green (http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html), and the Royal Holloway team (http://www.isg.rhul.ac.uk/tls/) have a very simple message: "DO NOT USE RC4.". If there are other cryptographers out there who disagree with this, I would like to hear from them.

2. This might be confusing, because a few months ago, these same cryptographers were warning you not to use CBC mode, but that has been mitigated (mostly) on the client-side.

3. But, point 2 doesn't really matter to this, because the problem is *CBC mode*, not 3DES. AES-CBC is exactly as vulnerable to the BEAST attack as 3DES-CBC is.

4. There is no known real-world cryptanalytic attack on 3DES. I'm guessing that the way 3DES even got roped into this discussion is that someone confused DES, which is very weak and was obsoleted about 20 years ago, with 3DES. https://wiki.mozilla.org/Security/Server_Side_TLS says "DES and 3DES contains all legacy ciphers that use the deprecated Data Encryption Standard". It isn't clear what it means by "legacy" and "deprecated", but in any case DES is unsafe, and 3DES is — as far as anyone has shown in the open literature — safe.

5. When there is no active attack in progress, then only a tiny fraction of people would be effected by this change — only users of IE8/WinXP.

6. But, if an attacker is willing and able to run an active attack, and knows how to attack RC4, then *all* users who use a server configured with Mozilla's current recommendations would be vulnerable. This is because in an active attack, the attacker can trick the client and server into "downgrading" to any cipher that both of them will accept, so by marking RC4 as acceptable in your server, you potentially render *all* users vulnerable to this. (Except users whose client refuses to use RC4 under any conditions.)

7. On the other hand, if an attacker is willing to run an active attack, and knows how to attack CBC (a la BEAST), then this change does *not* make the users any more vulnerable to such an attacker, because such an attacker can use AES-CBC anyway.

I think those are the facts. Please let me know if any of them are incorrect.

Comment 6

[Frederik Braun [:freddy]]

(In reply to Julien Vehent [:ulfr] from comment #2)
> Between RC4 and 3DES, I'm not sure which one is the most dangerous.

RC4, really.

Comment 7

[Julien Vehent]

> "DES and 3DES contains all legacy ciphers that use the deprecated Data Encryption Standard"

I wrote this. It's not accurate enough, I agree. It should read that DES is broken, and 3DES very slow.

As far as I know, this is the first time that replacing RC4 with 3DES is proposed. Like I said before, I am not against it, since it concern a small population only. But the message I'm getting from the community is more like "Use AES and not RC4" (which we do), and not "Use 3DES and not RC4".

RC4, albeit weakened, is still ~30 times faster than 3DES. Performance is an important factor, especially on systems that are old and most likely very slow. Before replacing RC4 with 3DES, I would like to hear the opinions of more cryptographers.

Comment 8

[Frederik Braun [:freddy]]

Sorry, didn't mean to troll. I'm trying to make up for this by sorting out some bug metadata ;)

Comment 9

[Daira Hopwood]

Attacks against RC4 are getting better all the time. The biases are not limited to the first 256 bytes, and are already on the verge of being practically exploitable against stereotyped data sent near the beginning of the stream, such as cookies. I strongly recommend never negotiating RC4 ciphersuites.

It could be argued the same clients that will negotiate RC4 are probably (well, certainly) vulnerable to other attacks. However, I don't see this as a good reason to negotiate RC4.

Comment 10

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I agree that it is better to prefer 3DES over RC4. That would be consistent with the client-side recommendations I made at https://briansmith.org/browser-ciphersuites-01.html.

Since your recommendations are for servers, I recommend that you simply recommend disabling RC4 entirely, based on my limited understanding of the compatibility issues. This requires TLS_RSA_WITH_3DES_EDE_CBC_SHA, at least, to be supported because of those old browsers on Windows. It is worth considering suggesting TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA too so that there is an ephemeral key exchange alternative to AES.

The argument that IE6/7/8 on Windows XP is "only" 2% of users doesn't seem to be an argument in favor of RC4 over 3DES. Either 2% of people is a lot of people in which case it is worth giving them extra protection, or 2% of people is not a lot of people so the performance hit of 3DES won't matter much.

Zooko's argument that an attacker can use AES-CBC whenever it wants to do BEAST is mostly correct, except for the case where the browser does not support AES-CBC, which is the primary case that we're talking about here.

Comment 11

[Nick Lowe]

See: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01

Comment 12

[Guillaume Destuynder [:kang] [this account is no longer active]]

Note that, 3DES is several magnitudes slower than RC4, and even more than AES with AESNI (which is what most servers have for AES acceleration nowadays).
One could perhaps conceive a DOS attack simply consisting of a botnet of 3DES clients.

See also http://dl.dropboxusercontent.com/u/24257718/cipher_chart.png for example (source http://zombe.es/post/4078724716/openssl-cipher-selection) (thats on a relatively decent xeon)

I also wouldn't be surprised if old "WinXP" computers plugged on today's fast DSL/cable/fiber would go to 100% CPU while downloading large pages served via 3DES.

This doesn't mean RC4 is not weakened (albeit AFAIK not actually fully broken yet, by the general public at least), but the choice seems non-trivial from an operational point of view.

I suppose it could be argued that, it might even be better to use zero encryption than a weakened cipher in order to prevent a false sense of security, which is a whole another can of worms.

Of course, this issue will probably happen again and again in the future with other ciphers and old clients.

My current opinion would be:

- test how many 3DES connections can be served by a load balancer/http server and use that to define the minimum hardware required versus how many connections should be supported by the lbl/server, OR
- drop support for legacy clients altogether (remove 3DES/RC4 support), OR
- enable RC4 instead of 3DES for a little while longer, inform about the risk (that's what the document currently recommend)

Maybe it would make sense to document it that way and leave the decision up to the operational team/individual reading and implementing the ciphersuite on his/their lbls/servers.

Comment 13

[Guillaume Destuynder [:kang] [this account is no longer active]]

Made some tests of my own... which hopefully aren't too flawed.

Intel E6400 - OpenSSL 1.0.1e:

openssl s_server -cert 2048-rsa.pem -WWW &
openssl s_time -connect localhost:4433 -www /1M -new [-ssl3] -cipher <cipher> -time 5

File 1M is 1Mb in size. 2048-rsa.pem uses a 2048bit RSA key as per the name.

ECDHE-RSA-RC4-SHA: 232 connections in 1.21s; 191.74 connections/user sec, bytes read 243280072
ECDHE-RSA-DES-CBC3-SHA: 220 connections in 1.36s; 161.76 connections/user sec, bytes read 230696620
ECDHE-RSA-AES128-GCM-SHA256: 242 connections in 1.24s; 195.16 connections/user sec, bytes read 253766282
ECDHE-RSA-AES256-GCM-SHA384: 263 connections in 1.37s; 191.97 connections/user sec, bytes read 275787323

Similar test, on insecure.ws (served by Apache 2.4 locally, 4096 bits RSA key, 4096 bits DH param):
ECDHE-RSA-RC4-SHA: 221 connections in 0.30s; 736.67 connections/user sec, bytes read 67626
ECDHE-RSA-DES-CBC3-SHA: 220 connections in 0.37s; 594.59 connections/user sec, bytes read 67320
ECDHE-RSA-AES128-GCM-SHA256: 239 connections in 0.29s; 824.14 connections/user sec, bytes read 73134
ECDHE-RSA-AES256-GCM-SHA384: 203 connections in 0.27s; 751.85 connections/user sec, bytes read 62118

This makes 3DES (very) roughly 20% slower than RC4.

So, it's not actually as bad and I suspect the tests linked from comment 12 aren't all that accurate (in fact, thats what triggered my curiosity).
It might also be that openssl s_server is not that good and that a test with a real client gives more accurate results. But if not, I would say that having 3DES in front of RC4 would be a sensible choice.

Due to bug 889749 (compatibility issues) I would not recommend disabling RC4 just yet obviously. @needinfo jvehent to validate the test procedure (or invalidate ;-)

Comment 14

[Julien Vehent]

I reran this test against nginx with a single worker:

$ openssl s_time -connect linuxwall.info:443 -www /bigrandom -new -time 300 -cipher 'RC4-SHA'
$ openssl s_time -connect linuxwall.info:443 -www /bigrandom -new -time 300 -cipher 'DES-CBC3-SHA'

'bigrandom' is a 10MB file from /dev/urandom
I measured the cpu usage of the nginx worker usage this script: https://gist.github.com/jvehent/7040980
This isn't a lab environment, there are other processes running on the box. But this particular nginx worker didn't serve any other traffic during the tests.

The results show a large difference of CPU usage between 3DES and RC4. RC4 uses 1 to 2% CPU time, 3DES is closer to 25%.
chart http://4u.1nw.eu/CPU_usage_3DES_RC4.png
row data http://4u.1nw.eu/cpu_usage_3des_rc4.ods

I haven't pushed the tests far enough to be able to confirm the risk of DOS, but the cost in CPU time is a reality. If we are going to prefer 3DES on *.mozilla.org, we need to evaluate the CPU impact first, and look at how many clients still negotiate RC4.

Comment 15

[Julien Vehent]

For accuracy, the average CPU usages are:
* 12.55% for TLS_RSA_WITH_3DES_EDE_CBC_SHA
*  0.38% for TLS_RSA_WITH_RC4_128_SHA

Comment 16

[Julien Vehent]

From a cryptographic point of view, 3DES is clearly safer than RC4. RC4 should not be used whenever possible.
On the other hand, 3DES has important performance issues, that must be taken into account before preferring it on large infrastructure.

Additionally, there might be hard dependencies to RC4 (bug 889749) that would prevent us from disabling it entirely.

I summarized this in the wiki page: https://wiki.mozilla.org/index.php?title=Security%2FServer_Side_TLS&diff=732200&oldid=732074

On Mozilla's sites, we will review our traffic patterns. If we find that replacing RC4 with 3DES is acceptable from a resources & performances standpoint, and that it doesn't break anything, we will update our configurations.

Thanks again for the help with the guidelines!

Comment 17

[zookog]

For what it is worth, the qualys ssllabs handshake simulator has been upgraded to add Bing, GoogleBot, Yahoo, and a few other things:

https://www.ssllabs.com/ssltest/analyze.html?d=zooko.com

Also, I tweaked my config for zooko.com, leaving the ciphers string intact as I earlier reported ("ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-ECDSA-AES128-SHA:DES-CBC3-SHA"), but I tweaked my config by adding SSLv3 to the set of supported protocols, which was previously only TLSv1, TLSv1.1, and TLSv1.2. By adding SSLv3 to the set of supported protocols, the only change on the ssllabs handshake simulator was that IE6/XP became able to connect to zooko.com. (Obligatory link to Microsoft's "PLEASE STOP USING IE6" site: http://www.ie6countdown.com/ .)

Comment 18

[zookog]

For what it is worth, I've been persuaded by Adam Langley and Nick Matthewson that GCM is hard to implement in a timing-leak-safe way, and I've decided that SHA-1 is just as good as SHA-256 when used in HMAC, so I tweaked my config string to this:

   ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA:DHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA256:DHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-ECDSA-AES128-GCM-SHA256:DES-CBC3-SHA

Comment 19

[Henri Sivonen (:hsivonen)]

(In reply to zookog from comment #17)
> By adding
> SSLv3 to the set of supported protocols, the only change on the ssllabs
> handshake simulator was that IE6/XP became able to connect to zooko.com.
> (Obligatory link to Microsoft's "PLEASE STOP USING IE6" site:
> http://www.ie6countdown.com/ .)

Unfortunately, the Mozilla servers on the path from landing on the Mozilla front page to successfully downloading Firefox should probably keep working from IE6. After all, XP users should be able to download Firefox and use it for the public Web even if they are stuck with IE6 for intranet reasons.

For services that aren't on the path to Firefox download, it probably makes sense not to worry about IE6.

Comment 20

[Hubert Kario]

I'm not sure if the argument for RC4 over 3DES because of possibility of DDoS is actually valid for this guide.

The same guide recommends enabling DHE suites which require very complex processing on the server and relatively simple one on client, so much so, that a single computer can DoS few quite fast servers and still make the request look completely legitimate.

As such, I think the default recommendation should include 3DES, not RC4.

Comment 21

[Julien Vehent]

Update: we've done some tests, and 3DES will replace RC4 in the recommendation and on mozilla servers in the very near future.