RC4 attacks: Can RC4 encryption algorithms protect SSL/TLS?

Can you introduce the problems found in the RC4 encryption algorithm recently? In this regard, what security risks do HTTPS network connections face? How should enterprises ensure that they are not attacked by this vulnerability?

Michael Cobb:RC4 (Rivest password 4) was designed by Ron Rivest of RSA Security in 1987. Due to its speed and simplicity, this encryption algorithm has become the most widely used stream password. It is used in common protocols, including Wired Equivalent Security (WEP), security algorithms for wireless networks, and HTTPS Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols; in fact, about 50% of all TLS traffic is currently protected using the RC4 algorithm. However, over the years, vulnerabilities found in this algorithm indicate that RC4 is about to end.

Dan Bernstein, a professor at the University of Illinois, recently disclosed a vulnerability in RC4 that allows attackers to restore a limited amount of plain text content from TLS connections encrypted using RC4. This RC4 attack applies to SSL and TLS of all versions that support the encryption algorithm. This attack against RC4 is possible because the encrypted ciphertext stream has a statistical defect, which leads to leakage of some encrypted information and provides sufficient samples for attackers to analyze.

This vulnerability does not directly threaten SSL/TLS users, because it is a multi-session attack and is unlikely to be implemented yet. Attackers must be able to capture network traffic between the client and the server, and repeatedly send the same encrypted content in the same location in the email. Even If attackers capture this information, they can only recover a small amount of information. However, the HTTP message has a stylized header, which is the same in the dialog, so the cookie content may be captured, especially when a more effective method to exploit this vulnerability occurs. If attackers can access data stored in cookies, this poses a huge risk to enterprises. Because cookies are usually used to store user account information or session tokens for identity authentication, so that users do not need to log on repeatedly. If attackers can intercept these cookies, they can impersonate users or access sensitive data in infected websites or services.

SSL/TLS supports adding and selecting different algorithms, but the main web browser does not support the latest and more secure algorithms. TLS 1.2 supports AEAD (encryption authentication with associated data) encryption, but this version of TLS has not been widely deployed. In addition to Safari running on iOS, the main browser either does not support it at all or closes it by default. To this end, you can change the way TLS uses RC4, but you need to change the TLS deployment of each client and server and be able to withstand the improved RC4 attack methods in the future.

Now, the administrator can deploy TLS 1.0 or TLS 1.1. Both versions use the CBC-mode encryption technology-which has been fixed for BEAST and Lucky Thirteen attacks. These attacks cause many administrators to switch to the RC4 instead of the CBC mode. Because TLS is an encryption protocol used to protect Internet traffic, its deployment needs to be more stable and not vulnerable to attacks, even those attacks are not practical at present. We hope this latest discovery will push the industry to release a safer version.