Intent to ship: RC4 disabled by default in Firefox 44

[Richard Barnes]

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.

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

[Richard Barnes]

Speaking of other browsers, the corresponding Chromium thread is here:

https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ

[Richard Barnes]

And from Microsoft:

http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/

[Masatoshi Kimura]

On 2015/09/02 1:56, Richard Barnes wrote:
> * 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

The whitelist contains not only RC4-exclusive servers but also TLS
version intolerant servers.
That said, it would not be a big deal because Chrome 45 has disabled
insecure fallback to TLS 1.0 [1].

[1] https://code.google.com/p/chromium/issues/detail?id=498998

[Tanvi Vyas]

Do we know if Chrome or IE will have a fallback UI?

>>> * 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
>>>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Richard Barnes]

Hearing no objections, let's consider this the plan of record.

Thanks,
--Richard

[Daniel Holbert]

On 09/01/2015 09:56 AM, Richard Barnes wrote:
> # 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.

One affected family of sites are American Airlines & US Airways. I
can't load any of the following sites, and as a result I was unable to
checkin for some recent flights in Firefox Nightly:

https://aa.com/
https://www.aa.com/
https://aavacations.com/
https://www.usairways.com/
https://checkin.usairways.com/

It may be (as mentioned in the text quoted above) that these sites are
visited at a low rate, but when users do need to visit them (e.g. for
flight checkin), it's pretty high-priority that they work.

Do we have tech evang plans to tell these sites & any other prominent
affected sites about the issue & pressure them to fix it? If they're not
even aware of the problem, and we end up being the first mover here
(say, because other browsers decide to punt for a release or two), I'd
hate for us to get the reputation as the Browser Which You Can't Rely On
To Check In For Your Flights.

(We've had tech evang bugs filed on American & US Airways for 6 months:
https://bugzilla.mozilla.org/show_bug.cgi?id=1141604
https://bugzilla.mozilla.org/show_bug.cgi?id=1142703
but I'm not aware of any actual outreach that's happened, aside from me
sending American a twitter-ping, which more than likely ended up in
their /dev/null.)

~Daniel

[k.o...@gmail.com]

[zombi...@gmail.com]

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 2017,

[zombi...@gmail.com]

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

[akayl...@gmail.com]

[akayl...@gmail.com]

On Tuesday, September 1, 2015 at 9:56:28 AM UTC-7, Richard Barnes wrote:

[mohammed.h...@gmail.com]

On Tuesday, September 1, 2015 at 9:56:28 AM UTC-7, Richard Barnes wrote:

[shiv88...@gmail.com]

[bbes...@gmail.com]

[thinkpa...@gmail.com]

[felicia...@gmail.com]