k***@gmail.com
2016-09-08 09:28:20 UTC
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 status
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.
* 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
* 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
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 status
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.
* 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
* 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