Google, Mozilla, Microsoft to Sever RC4 Support in Early 2016

Google and Mozilla today announced they’ve settled on a timeframe to permanently deprecate the shaky RC4 encryption algorithm.

Google, Microsoft and Mozilla today announced they’ve settled on a timeframe to permanently deprecate the shaky RC4 encryption algorithm.

Attacks against RC4 are growing increasingly practical, rendering the algorithm more untrustworthy by the day. The browser makers plan to sever support for RC4 in late January, early February 2016.

Mozilla’s Richard Barnes said the shut-off date should coincide with the release of Firefox version 44, slated for Jan. 26. Google’s Adam Langley said the Chrome release will reach a stable channel in either January or February, but would not specify a date, only that HTTPS servers supporting only RC4 will stop working.

“Disabling RC4 will mean that Firefox will no longer connect to servers that require RC4,” Barnes said in a post to the Mozilla developer platform forum. “The data we have indicate that while there are still a small number of such servers, Firefox users encounter them at very low rates.”

Langley wrote to the security@chromium.org mailing list: “When Chrome makes an HTTPS connection it has an implicit duty to do what it can to ensure that the connection is secure. At this point, the use of RC4 in an HTTPS connection is falling below that bar and thus we plan to disable support for RC4 in a future Chrome release.”

Currently, Firefox Beta and Release versions do not restrict RC4, but yet only 0.05 percent and 0.08 percent of connections to the respective versions use RC4. Google’s numbers are slightly higher for Chrome, 0.13 percent.

“Even then, affected server operators can very likely simply tweak their configuration to enable a better cipher suite in order to ensure continued operation,” Langley wrote.

Microsoft announced end of life for RC4 in Microsoft Edge and Internet Explorer 11, and that it will be disabled by default.

“Microsoft Edge and Internet Explorer 11 only utilize RC4 during a fallback from TLS 1.2 or 1.1 to TLS 1.0. A fallback to TLS 1.0 with RC4 is most often the result of an innocent error, but this is indistinguishable from a man-in-the-middle attack,” said David Walp, Senior Program Manager, Microsoft Edge. “For this reason, RC4 will be entirely disabled by default for all Microsoft Edge and Internet Explorer users on Windows 7, Windows 8.1 and Windows 10 starting in early 2016.”

For more than a decade, researchers have been poking holes in RC4, finding biases in the stream cipher’s not-so random bytes used to encrypt plaintext. An attacker with enough time and processing power and access to enough TLS requests could figure out plaintext.

In 2013, research done by the University of Illinois’ Daniel J. Bernstein arrived at a practical attack against a known weakness in RC4 that leads to a TLS session compromise, one of the first feasible attacks to be made public.

In July, Belgian researchers published attacks against RC4 that allows a hacker to capture and decrypt a cookie much quicker than ever before.

The paper “All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS,” written by Mathy Vanhoef and Frank Piessens of the University of Leuven, explains the discovery of new biases in the algorithm that led to attacks breaking encryption on websites running TLS with RC4, as well as the WPA-TKIP, the Wi-Fi Protected Access Temporal Key Integrity Protocol, in order to recover cookies.

Vanhoef and Piessens explain how an attacker can use these findings to decrypt a user’s website cookie, for example, that should be secured over an encrypted channel. Their attacks, however, are not limited to cookies.

“This means the attacker can perform actions under the victim’s name (e.g. post status updates and send messages), gain access to personal information (e.g. to emails and chat history), and so on,” the academics said.

Suggested articles