As part of our commitment to protect the privacy of our users, Mozilla will disable the insecure RC4 cipher in Firefox in late January 2016, beginning with Firefox 44. Mozilla will be taking this action in coordination with the Chrome and IE/Edge teams. If you’re a web site operator and still rely on RC4, you need to enable some other ciphers, or Firefox users will be unable to reach you. Very few servers rely exclusively on RC4, so most users should experience minimal disruption.
The Rise and Gradual Fall of RC4
Developed in 1987 by Ron Rivest, the RC4 cipher has been a staple of cryptography for almost 30 years. For many years, RC4 was widely used by HTTPS servers: first because it was faster than contemporary alternatives, and later because it was immune to attacks that other ciphers were vulnerable to, such as BEAST.
Over the years, however, cryptanalysis of RC4 has resulted in better and better attacks against it. It has been known since 1995 that RC4 has certain biases that make it easier to attack. Recently, several practical attacks against RC4-protected HTTPS sessions have been demonstrated. This led the IETF to publish RFC 7465, which forbids the use of RC4 in TLS.
At the same time, newer ciphers such as AES-GCM have been created, which are as fast as RC4 on modern hardware, and are also immune to attacks such as BEAST. Most web servers support these newer ciphers, and the majority of Firefox TLS transactions already use them.
Deprecation of RC4 in Firefox
Until recently, RC4 was fully supported by Firefox to maintain compatibility with older servers, but over the past year, we’ve been gradually removing support.
In Firefox 36 (released in February 2015), we took the first step by making RC4 a “fallback-only” cipher. With that change, Firefox would first try to communicate with the server using secure ciphers, before “falling back” to RC4. As a result, Firefox would only use RC4 if the server didn’t support anything better. That was a major step; over the course of the following weeks, RC4 usage by Firefox dropped from around 27% of TLS transactions to less than 0.5%.
In Firefox 38 (released in May 2015), we took a further step by disabling RC4 almost entirely in our pre-release Nightly and Developer Edition products, leaving it enabled only for a small whitelist of sites. Web developers using those products to test their sites will have already seen breakage if their site requires RC4. Perhaps as a result of this, RC4 usage by Firefox has continued to gradually decline, to the point where it’s currently used in only 0.08% of TLS transactions.
Disabling RC4 by Default
RC4 will no longer be offered by default in TLS fallback beginning with Firefox 44, set to be released on January 26, 2016. As a result, Firefox will refuse to negotiate RC4 with web servers. We are announcing this change now in order to provide website operators with time to update their websites.
As noted above, the share of Firefox TLS communications using RC4 has fallen from approximately 27% at the end of 2014 to only .08% at present. As such, Mozilla expects the impact from this change to be minimal and localized to a small number of websites that currently only offer RC4 and are unable to upgrade prior to January.
Mozilla maintains a set of guidelines on TLS configurations and a TLS configuration generator to assist website operators in the selecting a secure configuration for their websites. Although it is recommended that website operators remove the availability of RC4 entirely, those that require compatibility with older clients such as Internet Explorer 6 may want to continue to offer RC4. As long as more modern ciphers suites containing AES are also available, Firefox will use those more secure options instead of RC4.
Users that would like to disable RC4 fallback prior to the January release may set the security.tls.unrestricted_rc4_fallback setting inside of about:config to false. After that preference is set to false by default in Firefox 44, users that still require RC4 may re-enable it by setting it back to true.