Could you explain the recent flaw that was discovered in the RC4 encryption algorithm? What are the practical security implications for the security of HTTPS Web connections, and how should organizations ensure they won’t be vulnerable to an attack on the weakness?

RC4 (Rivest Cipher 4) was designed by Ron Rivest of RSA Security back in 1987 and has become the most widely used stream cipher because of its speed and simplicity. It’s used in common protocols such as Wired Equivalent Privacy (WEP), a security algorithm for wireless networks, and the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols of HTTPS; in fact, around 50% of all TLS traffic is currently protected using the RC4 algorithm. However, weaknesses have been found in the algorithm over the years indicating that, RC4’s life is coming to the end.

A flaw disclosed recently by Dan Bernstein, a professor at the University of Illinois, allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The RC4 attack applies to all versions of SSL and TLS that support the algorithm. The attack on RC4 is possible because of statistical flaws in the keystream generated by the algorithm that reveals parts of encrypted messages, provided the attacker can obtain enough samples to analyze.

This flaw doesn’t represent an immediate threat to users of SSL/TLS as it’s a multi-session attack that is currently impractical to mount. An attacker would have to be able to capture network traffic between a client and server, as well as the same encrypted plaintext being sent at the same fixed location in a message over and over. Even if this scenario was realized, the attacker would be able to recover only a small portion of the message. However, HTTP messages have stylized headers that are identical across a conversation, so the contents of a cookie could potentially be captured, particularly once more effective methods that exploit this weakness begin to emerge. There are huge dangers with an attacker being able to access data stored in a cookie. For example, cookies are often used to store user account information or a session token needed to authenticate so users don’t have to log in repeatedly. If an attacker can hijack these cookies, they could impersonate the user or access sensitive data within the affected site or service.

The SSL/TLS protocol does support the addition and selection of different algorithms, but the major Web browsers don’t all support the latest and more secure algorithms. TLS 1.2 supports AEAD (Authenticated Encryption with Associated Data) cipher suites, but this version of TLS hasn’t been widely adopted yet. The major browsers, apart from Safari running on iOS, either don’t support it or have it turned off by default. Alternatively, you could change the way TLS uses RC4, but it would need to be realized in every client and server implementation of TLS and be able to withstand future improvements in the RC4 attack method.

For now, administrators can deploy an implementation of TLS 1.0 or TLS 1.1, both of which use a CBC-mode cipher suite that has been patched against the BEAST and Lucky Thirteen attacks. Ironically, these attacks led many administrators to switch to using RC4 instead of CBC-mode. As TLS is the encryption protocol used to secure Internet traffic, its implementation needs to be rock solid and not vulnerable to attacks, even those that may not be practical. Hopefully this latest discovery will prompt a move to a more secure version.

Article Source