Anthony-Lecorchick-photo
Security Research Engineer at Ixia
Blog

The Death of RC4 in TLS

February 10, 2016 by Anthony Lecorchick

artic-seal ​In February 2015, the Internet Engineering Task Force (IETF) released RFC 7465, prohibiting the RC4 cipher suite in TLS. At this point, the IETF considers RC4 to be “on the verge of becoming practically exploitable...[and] can no longer be seen as providing a sufficient level of security for TLS sessions.”

 

The Evolution of RC4

RC4 is a stream cipher, a type of symmetric key cipher designed to encrypt a continuous stream of data. Data is encrypted using a keystream, a pseudorandom series of bits that the message is XORed against. The keystream is derived using a symmetric key, or a shared piece of information, usually a very large number. Any party who knows the key and the algorithm used can decrypt the message.

The RC4 stream cipher was created in 1987, but remained a trade secret until it was leaked in 1994. Within a few years it became a commonly used cipher in other encryption protocols, including within WEP, SSL, and TLS.

 

Cracks Appear in RC4 Security

By 1995, the first weaknesses in RC4 began to show. Andrew Roos discovered that for certain weak keys, “the initial byte of the pseudo-random stream generated by RC4 is strongly correlated with only a few bytes of the key.” This would allow an attacker who noticed this correlation to attempt an exhaustive key search, or brute force attempt to decrypt the message by trying every key, with a reduced set of keys, thus reducing the time and resources required to crack it.

 

In 2001, a whitepaper released by Scott Fluhrer, Itsik Mantin, and Adi Shamir detailed two weaknesses in the RC4 key scheduling algorithm, the method by which RC4 creates “subkeys” from the cryptographic key to encrypt the data stream. The first allowed RC4 traffic to be distinguished from random traffic, and the second allowed derivation of the key from a large amount of traffic in certain use cases. The latter case was used to break WEP encryption, commonly used in wireless networks at the time, using what became known as the “FMS attack,” named for the above authors. Mantin and Shamir further expanded the attacks in another whitepaper the following year, allowing for the distinguishing of RC4 traffic from random traffic in the case where the same plaintext was sent to multiple recipients with different keys. It should be noted that only a specific mode in RC4 was broken at this point; RC4 was still considered cryptographically secure in other modes.

 

In his 2006 whitepaper, Andreas Klein expanded the FMS attack by finding further correlations between the keystream and the key within RC4, reducing the number of sessions and prior knowledge needed to crack the encryption key. The methodology used in Klien's whitepaper was implemented by Erik Tews, Ralf-Philipp Weinmann, and Andrei Pychkine in the tool aircrack-ptw, now part of the aircrack-ng tool suite.

 

In a 2013 whitepaper by Nadhem J. AlFardan, Daniel J. Bernstein, Kenneth G. Paterson, Bertram Poettering, and Jacob C. N. Schuldt presented two ciphertext-only plaintext recovery attacks on RC4 encryption in TLS, attacks that decrypt the encrypted message using nothing but the encrypted ciphertext. These Royal Halloway attacks, named for the university for which four of the five researchers worked, require specific circumstances, and require a large amount of ciphertext, thus may not be practical for real-world attacks. However, they also speculate the possibility of expanding to better attacks, which would make this possible. This research was especially timely, as RC4 had become the cipher-of-choice in response to the 2011 BEAST attacks against other TLS ciphers.

 

This brings us to RFC 7465, where the above research is cited as reason to completely discontinue use of RC4 in TLS. Google Chrome discontinued use with Chrome 48 on January 20, 2016. Mozilla has retired RC4 in Firefox 44, as of January 26, 2016. Likewise, Microsoft has announced they will end support for RC4 in Microsoft Edge and Internet Explorer 11 in early 2016.

In the meantime, yet more problems for RC4 have been made public. In March 2015, Itsik Mantin presented his "Bar Mitzvah attack" at Blackhat Asia, allowing additional plaintext recoveries with certain keys, often allowing the recovery of authentication tokens or other specific sensitive data.

 

Most recently at the time of this writing, in August 2015, Mathy Vanhoef and Frank Piessen released a whitepaper at USENIX 2015 detailing their RC4NOMORE attack, which allowed them to recover web cookies from RC4-encrypted sessions in 75 hours using a rate of 4450 requests per second. The attack can be extended to any repeatedly encrypted data, such as authentication credentials.

 

RC4 Testing to Make Your Network More Secure

As stated above, the simplest way to defend against this is to disallow RC4 in TLS. With the popular browsers cutting support, most web hosts are moving to alternative ciphers, meaning they will no longer allow establishing a connection using the RC4 algorithm. Responsible Internet-facing web hosts are moving to more secure algorithms and most Internet browser applications will automatically be updated to prevent using RC4. However, not all web hosts perform necessary updates, nor do all clients keep their browsers updated.

Detection of RC4 in a TLS handshake is simple. During a Client Hello, the client passes a list of supported ciphers. Updated browsers will not include any of the RC4 ciphers listed in RFC 7465. If it contains only ciphers from this list, it may be that a man-in-the-middle attacker is attempting to force the use of an insecure cipher, otherwise known as a downgrade attack. During the Server Hello portion of the handshake, the server selects a cipher from the client's supported cipher list. The selected cipher should not be one from the list of deprecated RC4 ciphers.

To test your own capabilities, the latest ATI Update includes a strike (A15-56001) that starts a TLS handshake using one of the vulnerable ciphers listed in RFC 7465.

 

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.