Closed Bug 1386754 Opened 7 years ago Closed 7 years ago

Disable 3DES in TLS Handshake for Nightly builds

Categories

(Core :: Security: PSM, enhancement, P1)

Product:
Core
Component:
Security: PSM
Version:
57 Branch
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla57
Tracking Flags:
Tracking Status
firefox57 --- fixed

People

(Reporter: jcj, Assigned: jcj)

References

Details

(Keywords: dev-doc-complete, site-compat)

Attachments

(1 file)

Bug 1386754 - Deprecate 3DES on nightly builds
59 bytes, text/x-review-board-request
dveditz
: review+
Details 
3DES usage is well below 1% [1]. A recent TLS Canary run with "security.ssl3.rsa_des_ede3_sha" disabled showed 825 of 500,000 sites being affected by deprecating 3DES [2]. I believe it's time to start the deprecation by disabling the preference in non-release builds on the 57 branch.

For this bug, we should engage with evangelism to contact known-impacted sites where possible.

Before we do this for release builds, we'll need to pull in documentation support... but that is probably not this bug.

[1] https://mzl.la/2uNt0BP
[2] https://tlscanary.mozilla.org/runs/2017-08-01-17-07-49/
Dan - I've made the trivial patch, but I particularly want your review on a plan to let this land for 57 nightly, ride to beta, and hang in those non-release builds for now, and re-assess a cut-off for Release in Q4 or Q1.
Flags: needinfo?(dveditz)
Comment on attachment 8893020 [details]
Bug 1386754 - Deprecate 3DES on nightly builds

https://reviewboard.mozilla.org/r/164032/#review169428

::: security/manager/ssl/security-prefs.js:32
(Diff revision 1)
>  pref("security.ssl3.dhe_rsa_aes_128_sha", true);
>  pref("security.ssl3.dhe_rsa_aes_256_sha", true);
>  pref("security.ssl3.rsa_aes_128_sha", true);
>  pref("security.ssl3.rsa_aes_256_sha", true);
> +// Deprecate 3DES on non-release builds, Bug 1386754
> +#ifdef RELEASE

RELEASE_OR_BETA
(In reply to Masatoshi Kimura [:emk] from comment #3)
> > +#ifdef RELEASE
> 
> RELEASE_OR_BETA

In comment 2 jcj said he wanted 3DES to be disabled on beta, but given the high profile of 57 I agree that we probably don't want to be breaking sites on 57 beta that we don't intend to break in that release. It will just add to the confusion and pressure for people working on shipping that release. I'd be more comfortable waiting until 58 to let it ride to beta (but fine to disable it on nightly now).

0.4% is quite a bit higher than where we were comfortable turning off RC4.

In the canary results SSL_ERROR_NO_CYPHER_OVERLAP makes sense, but why are so many returning PR_END_OF_FILE_ERROR? What ciphersuites do Edge and Chrome use to connect to those sites?
Flags: needinfo?(dveditz)
Comment on attachment 8893020 [details]
Bug 1386754 - Deprecate 3DES on nightly builds

https://reviewboard.mozilla.org/r/164032/#review169498

::: security/manager/ssl/security-prefs.js:32
(Diff revision 1)
>  pref("security.ssl3.dhe_rsa_aes_128_sha", true);
>  pref("security.ssl3.dhe_rsa_aes_256_sha", true);
>  pref("security.ssl3.rsa_aes_128_sha", true);
>  pref("security.ssl3.rsa_aes_256_sha", true);
> +// Deprecate 3DES on non-release builds, Bug 1386754
> +#ifdef RELEASE

Given the high profile of Fx57, I agree this should be RELEASE_OR_BETA for now.
Attachment #8893020 - Flags: review?(dveditz) → review-
(In reply to Daniel Veditz [:dveditz] from comment #4)
> (In reply to Masatoshi Kimura [:emk] from comment #3)
> > > +#ifdef RELEASE
> > 
> > RELEASE_OR_BETA
> 
> In comment 2 jcj said he wanted 3DES to be disabled on beta, but given the
> high profile of 57 I agree that we probably don't want to be breaking sites
> on 57 beta that we don't intend to break in that release. It will just add
> to the confusion and pressure for people working on shipping that release.
> I'd be more comfortable waiting until 58 to let it ride to beta (but fine to
> disable it on nightly now).

That sounds reasonable. I'll file a follow-on to switch this from RELEASE_OR_BETA back to RELEASE in 58, and I'll update the patch presently.

> 0.4% is quite a bit higher than where we were comfortable turning off RC4.

It is, but this time we have the TLS Canary results, which I don't believe we had when we were deprecating RC4. I figure we can start with Nightly, spin up the evangelism team, start talking about it, and re-assess where that puts our telemetry position in Q4 or Q1. Also, this might prompt Chrome or Edge to take up the cause, too.

> In the canary results SSL_ERROR_NO_CYPHER_OVERLAP makes sense, but why are
> so many returning PR_END_OF_FILE_ERROR? What ciphersuites do Edge and Chrome
> use to connect to those sites?

I tried several of the EOF error-giving sites using Chrome Canary and they all connected, reporting the ciphersuites:

https://sigalert.com - The connection to this site uses TLS 1.0 (an obsolete protocol), RSA (an obsolete key exchange), and 3DES_EDE_CBC with HMAC-SHA1 (an obsolete cipher).
https://abco.advisory.com - The connection to this site uses TLS 1.0 (an obsolete protocol), RSA (an obsolete key exchange), and 3DES_EDE_CBC with HMAC-SHA1 (an obsolete cipher).
https://airfare.com - The connection to this site uses TLS 1.0 (an obsolete protocol), RSA (an obsolete key exchange), and 3DES_EDE_CBC with HMAC-SHA1 (an obsolete cipher).

Without tracing NSS, I'd hazard a guess that some server software is just behaving badly when we don't advertise 3DES; we had something similar happen with RC4.
Comment on attachment 8893020 [details]
Bug 1386754 - Deprecate 3DES on nightly builds

https://reviewboard.mozilla.org/r/164032/#review169510

Looks good.
Attachment #8893020 - Flags: review?(dveditz) → review+
Blocks: 1386908
Marking site-compat, dev-doc-needed, and finally checkin-needed.

Note to dev-doc-folks: It's possible we can leave this be until we're making the change in Beta, which would be Bug 1386908, approximately Beta 58 or Beta 59.
Keywords: checkin-needed, dev-doc-needed, site-compat
Summary: Disable 3DES in TLS Handshake for non-release builds → Disable 3DES in TLS Handshake for Nightly builds
Version: 55 Branch → 57 Branch
We have no "RELEASE" configuration option in the first place. We have never distinguished beta from release. Do we really add a configuration option only for this bug?

The most approximate option would be EARLY_BETA_OR_EARLIER.
Autoland can't push this until all pending issues in MozReview are marked as resolved.
Flags: needinfo?(jjones)
Keywords: checkin-needed
Sorry about that, fixed. (And :emk, good call on EARLY_BETA_OR_EARLIER, that's what I want, will adjust the other bug)
Flags: needinfo?(jjones)
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/c147d7716c17
Deprecate 3DES on nightly builds r=dveditz
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/c147d7716c17
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Regarding historical breakage, I do have some data from TLS Canary. 

Apologies in that a) we did test RC4 breakage but didn't label the runs as such, and b) number of total sites tested wasn't always included in the report, which makes deriving exact breakage statistics impossible. That's a canary bug that I will fix ASAP.

In summary, 3DES breakage appears to have a smaller impact than other similar changes we've made. 

Logjam
[1] Fx40a2 Aurora 0.47% (999/211096)

RC4
[2] Fx44a2 Aurora 0.33% (696/211096)
[3] Fx44b Beta 0.25% (519/211096)

SHA-1
[4] Fx53.0a1 Nightly 0.45% (1323/290772)

3DES
[5] Fx56.0a1 0.18% (825/460500)

[1] https://tlscanary.mozilla.org/runs/2015-05-28-16-47-42
[2] https://tlscanary.mozilla.org/runs/2015-11-12-14-59-23
[3] https://tlscanary.mozilla.org/runs/2015-12-29-11-36-51
[4] https://tlscanary.mozilla.org/runs/2017-01-16-17-00-59
[5] https://tlscanary.mozilla.org/runs/2017-08-01-17-07-49
Running Nightly. Question for you. How do I get to this site presumably since this patch was released..  https://www.state.nj.us/treas/treasmail.shtml.  It works fine using MS Edge.
(In reply to Gary [:streetwolf] from comment #17)
> Running Nightly. Question for you. How do I get to this site presumably
> since this patch was released.. 
> https://www.state.nj.us/treas/treasmail.shtml.  It works fine using MS Edge.

Hi Gary,

You can re-enable the 3DES cipher by navigating to about:config [1], searching for "security.ssl3.rsa_des_ede3_sha" and toggling via double-click back to "true".

[1] http://kb.mozillazine.org/About:config
Thanks
Not being too familiar with the terminology used here, it's a bit confusing to me what will happen to 3DES support after FF57.
I understand that for now, I can enable 3DES support by toggling security.ssl3.rsa_des_ede3_sha to true, right until it reaches release, in November, right? (It's a bit vague whether this setting will be true or false by default in the release version, but that's a minor concern).
But then? Will 3DES support be removed entirely in v58 or v59? That's what I don't get.

The problem is that many of the websites hosted by my company do use older certificates, and I can't convince my boss to buy new ones before the old ones have expired. I.E. a lot of old ones will still be in use early next year.
(In reply to Pim Blokland from comment #20)
> [...]
> The problem is that many of the websites hosted by my company do use older
> certificates, and I can't convince my boss to buy new ones before the old
> ones have expired. I.E. a lot of old ones will still be in use early next
> year.

You can always get free certificate from Let's Encrypt - https://letsencrypt.org/.
Better block old obsolete and insecure ciphers, than be liable to security attack, which will cause users passwords and data stolen and breached.
Also note that certificates are different from cipher suites. You can change your servers to use more modern cipher suites without changing your certificates.
(In reply to Pim Blokland from comment #20)
> But then? Will 3DES support be removed entirely in v58 or v59? That's what I
> don't get.
> 

Hi Pim,

There's no timeline for disabling 3DES in Firefox Beta or Release yet (see Bug 1386908). I don't think we'd do it in 58 or 59, but we will do it eventually. We often test these sorts of deprecations in Nightly for a few releases before committing to a timetable for Release.
See Also: → 1393772
This change breaks https://dlc.iec.cat/
Note the Catalan localization of Firefox includes IEC's dictionary as a search engine.
Documented. This is still experimental, so I've added a note to the Experimental features page for now.

https://developer.mozilla.org/en-US/Firefox/Experimental_features#Security

I don't know if you expected more documentation than this. Our security section really needs an overhaul, and we were hoping to get to this soon.
Keywords: dev-doc-needed → dev-doc-complete
Perfect, thanks :kohei & :cmills!
Blocks: 1404464
I have found a few examples of broken sites because if this.  wlcsplash.airnz.co.nz broke for me.

What do we hope to gain by making this change?
Martin, the goal is to eventually be able to drop 3DES :-) There's no vulnerabilities so critical that we have to drop it ASAP, but between SWEET32, and the whole family of CBC issues, and the fact that it's one of 3 remaining non-FS suites, we'd like to drop it eventually.

Dropping it on nightly gives us the ability to survey the impact, and start reaching out to site owners to get them to resolve.
See Also: → 1405511
(In reply to Martin Thomson [:mt:] from comment #28)
> I have found a few examples of broken sites because if this. 
> wlcsplash.airnz.co.nz broke for me.
> 
> What do we hope to gain by making this change?

MT: The goal was to see how widely we'd affect site compat if we disabled 3DES, as overall usage was similar to RC4 when we shut it off. The TLS Canary doesn't reveal all the government sites that broke, nor the wifi splash sites and similar.

We collected two months of reports and telemetry, and now we know what to look for before we consider shutting it off in the future -- or even just sites that will need updates if some vulnerability is found.

Thanks to everyone for testing. Bug 1405511 turns this back on.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: