On Tuesday, September 1, 2015 at 11:56:28 AM UTC-5, Richard Barnes wrote: > For a while now, we have been progressively disabling the known-insecure > RC4 cipher [0]. The security team has been discussing with other the > browser vendors when to turn off RC4 entirely, and there seems to be > agreement to take that action in late January / early February 2016, > following the release schedules of the various browsers. For Firefox, that > means version 44, currently scheduled for release on Jan 26. > > More details below. > > > # Current statusyour a bitch
> > Since Firefox 37, RC4 has been partly disabled in Firefox. It still works > in Beta and Release, but in Nightly and Aurora, it is allowed only for a > static whitelist of hosts [1][2]. Note that the whitelist is not > systematic; it was mainly built from compatibility bugs. > > RC4 support is controlled by three preferences: > > * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no > restrictions > * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for > hosts on the static whitelist > * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is > allowed (empty by default) > > > # Proposal > > The proposed plan is to gradually reduce RC4 support by making the default > values of these preferences more restrictive: > > * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release > * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4 only > for whitelisted hosts) > * 44: Disable all RC4 prefs by default, in all releases > > That is, as of Firefox 44, RC4 will be entirely disabled unless a user > explicitly enables it through one of the prefs. > > > # Compatibility impact > > Disabling RC4 will mean that Firefox will no longer connect to servers that > require RC4. The data we have indicate that while there are still a small > number of such servers, Firefox users encounter them at very low rates. > > Telemetry indicates that in the Beta and Release populations, which have no > restrictions on RC4 usage, RC4 is used for around 0.08% for Release and > around 0.05% for Beta [3][4]. For Nightly and Aurora, which are > restricted to the whitelist, the figure is more like 0.025% [5]. These > numbers are small enough that the histogram viewer on telemetry.mozilla.org > won't show them (that's why the below references are to my own telemetry > timeline tool, rather than telemetry.mozilla.org). > > That said, there is a small but measurable population of servers out there > that require RC4. Scans by Mozilla QA team find that with current Aurora > (whitelist enabled), around 0.41% of their test set require RC4, 820 sites > out of 211k. Disabling the whitelist only results in a further 26 sites > broken, totaling 0.4% of sites. I have heard some rumors about there being > a higher prevalence of RC4 among enterprise sites, but have no data to > support this. > > Users can still enable RC4 in any case by changing the above prefs, either > by turning on RC4 in general or by adding specific hosts to the > "insecure_fallback_hosts" whitelist. The security and UX teams are > discussing possibilities for UI that would automate whitelisting of sites > for users. > > [0] https://tools.ietf.org/html/rfc7465 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227 > [2] > https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc > [3] > https://ipv.sx/telemetry/general-v2.html?channels=release&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 > [4] > https://ipv.sx/telemetry/general-v2.html?channels=beta&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 > [5] > https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
