1227524 - Establish deprecation date for 3DES

Status: RESOLVED DUPLICATE of bug 1724072

(Core :: Security: PSM, task, P3)

Description

[tranogatha]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151124004047

Steps to reproduce:

TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suit is old and we should make a date on which it will be considered deprecated and aim for its removal or at least no longer advertise it in the initial handshake.

Comment 1

[u580221]

Can you at least add a big fat warning if you don't want to fully block the sites already?
https://3des.badssl.com/ this test site is accepted without any warnings and uses triple-des.

It appears to be established that triple-des simply isn't secure anymore: http://news.softpedia.com/news/sweet32-attack-3des-and-blowfish-ciphers-considered-insecure-507631.shtml

How long do you want to wait before finally fading it out? The fact of it being insecure won't wait until you've made up your mind..

Comment 2

[Masatoshi Kimura [:emk]]

We have implemented a countermeasure that makes the sweet32 attack not effective since NSS 3.27 (Firefox 51) as written in the official Sweet32 website[1].

Of course we should disable 3DES in the future, but it is not so urgent.

[1] https://sweet32.info/#impact

Comment 3

[Christian Stadelmann]

(In reply to Masatoshi Kimura [:emk] from comment #2)
> We have implemented a countermeasure that makes the sweet32 attack not
> effective since NSS 3.27 (Firefox 51) as written in the official Sweet32
> website[1].

That's bug #1268745.

> Of course we should disable 3DES in the future, but it is not so urgent.

Is there any reliable data on how many connections are using 3DES? And how many of those sites will only work with 3DES enabled? According to the SSL pulse [2] the number of RC4-only pages went down to 12 (!) in Alexa's TOP 200k (or so, see "Methodology" on [2]). If disabling 3DES would add another 0.01% broken sites to the internet, wouldn't that be worth the security we'd gain? Anyway, since protocol downgrade attacks happen from time to time, any TLS implementation should not be considered stronger than its weakest active cipher, which would probably be 3DES.

[2] https://www.trustworthyinternet.org/ssl-pulse/

Comment 4

[Ruben]

> but it is not so urgent

sure this is urgent!

To decrypt a https-session only hardware worth only 10.000 Dollars is needed today that can search through the whole 3DES keyspace!

How can you say this is not urgent?

Comment 5

[Ruben]

Also 3DES should be disabled in Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=1167857

Comment 6

[Alex Gaynor [:Alex_Gaynor]]

If anyone is interested, https://mzl.la/2uNt0BP shows the relative usage of symmetric ciphers in TLS, looks like 3DES is currently at ~.4% of connections.

Comment 7

[J.C. Jones [:jcj] (he/they)]

Matt, can you please run a full TLS Canary run with the pref "security.ssl3.rsa_des_ede3_sha" set to false and give us the results?

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

There are 825 sites (out of roughly 500k top sites) that would be affected by this change. If you sort by rank, it gives a good idea of how common this might be.

Worth noting is that you can, of course, run these sites through an analysis tool like SSL Labs. I did so with a bunch of the top sites here and most of them have pretty outdated and insecure TLS configs as-is.

https://tlscanary.mozilla.org/runs/2017-08-01-17-07-49/

Comment 12

[Mateusz Jończyk]

I propose that Firefox would use 3DES only as a last resort - i.e. that it would ignore the server-preferred cipher order and do not use 3DES when the server supports other, better ciphers (like AES).
This way, website compatibility problems could be avoided.

For example, the website 
        https://ppuslugi.mf.gov
supports AES but prefers 3DES. This can be seen on
        https://www.ssllabs.com/ssltest/analyze.html?d=ppuslugi.mf.gov.pl
            # TLS 1.2 (suites in server-preferred order)
            TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK 	112
            TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK 	128
            TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK 	256

Currently, Firefox connects to this site using the 3DES cipher - as can be seen in "Page Info" -> "Security" or on the SSLTest page. Firefox should ideally connect to this site with AES.

Comment 13

[Mark Straver]

Isn't that already present functionality? Marking 3DES "weak" would prevent it from being offered in the initial handshake (see e.g. how RC4 fallback has been handled) and only used in the fallback handshake -- i.e. just flip the weak flag and you should be done.

Comment 14

[Masatoshi Kimura [:emk]]

We no longer fallbacks to lower TLS versions anymore that was a security weakness by itself.

Comment 15

[Mark Straver]

I must have misunderstood the mechanism then - I was under the impression that "unrestricted rc4 fallback" had nothing to do with TLS version and only with cipher suites?

If it's not working the way I thought though, then simply not offering 3DES (which is what this bug is about anyway) would also solve this situation already because it'll just use AES in that case no matter if the server prefers 3DES.

Comment 16

[Mateusz Jończyk]

(In reply to Masatoshi Kimura [:emk] from comment #14)
> We no longer fallbacks to lower TLS versions anymore that was a security
> weakness by itself.

Firefox could offer 3DES only on the second connection attempt - if the initial connection did not succeed. This would enable it to avoid 3DES and keep compatibility with old sites at the same time.

Yes, it would cause a weakness because a MITM-capable attacker could cause the first connection attempt to fail and therefore force 3DES --- but that would be much better then what Firefox is currently doing (advertising 3DES on the first attempt and using 3DES if the server prefers it). MITM attacks probably happen less frequently then passive eavesdropping.

Additionally, I think that Firefox should show warnings in the developer console when using 3DES.

Comment 17

[Eric Lawrence (@ericlaw)]

Chromium issue is https://crbug.com/691888

Comment 18

[Darkspirit]

"PSA: Moving SHA-1 and 3DES in TLS to a fallback"
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yaJcs4p9LNI

• 3DES: https://crbug.com/691888
• RSA+SHA1: https://crbug.com/658905 (bug 1600449, bug 1600437, SSLLabs)

Comment 19

[Daniel C]

There is now an "Intent to Remove" for this targeted for Chrome 93: https://groups.google.com/a/chromium.org/g/security-dev/c/ByMiYwr_5vA/m/J1mfUFuPAgAJ

Comment 20

[Mathew Hodson]

I think this bug can be marked as Depends on bug 1724072 and closed.

An intent email was sent at https://groups.google.com/a/mozilla.org/g/dev-platform/c/ayz0lLotyyU