Open Bug 1227524 Opened 5 years ago Updated 28 days ago
Establish deprecation date for 3DES
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.
Component: Untriaged → Security: PSM
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
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..
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. Of course we should disable 3DES in the future, but it is not so urgent.  https://sweet32.info/#impact
(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. 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  the number of RC4-only pages went down to 12 (!) in Alexa's TOP 200k (or so, see "Methodology" on ). 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.  https://www.trustworthyinternet.org/ssl-pulse/
> 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?
Also 3DES should be disabled in Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=1167857
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.
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?
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/
Depends on: 1386754
Depends on: 1386908
Priority: -- → P3
Whiteboard: [psm-deprecation] → [psm-deprecation][psm-blocked]
Duplicate of this bug: 1499759
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.
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.
We no longer fallbacks to lower TLS versions anymore that was a security weakness by itself.
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.
(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.
You need to log in before you can comment on or make changes to this bug.