Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

“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 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.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.