A new attack was discovered against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted at a fixed location across many TLS sessions. Reference: http://www.isg.rhul.ac.uk/tls/ http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html
CVE-2013-2566: The RC4 algorithm, as used in the TLS protocol and SSL protocol, has many single-byte biases, which makes it easier for remote attackers to conduct plaintext-recovery attacks via statistical analysis of ciphertext in a large number of sessions that use the same plaintext. Reference: http://cr.yp.to/talks/2013.03.12/slides.pdf
Additional media coverage: http://nakedsecurity.sophos.com/2013/03/16/has-https-finally-been-cracked/ http://www.theregister.co.uk/2013/03/15/tls_broken/
There has been a lot of discussion about this flaw in various upstream security lists and bugzilla's for products shipped in Red Hat Enterprise Linux which support RC4. The general consensus is that, this is really a RC4 design issue and there seems to be no way to correct this flaw. Some workarounds to this issue were suggested like doing 1/1/1/.../n-11 record splitting at the start of the TLS connection which will burn off the first 256 predictable keystream bytes. However there are other bytes in the RC4 keystream which have biases as well, so this is only a temporary solution. One solution is to switch over to AES-CBC mode (with fixes applied for BEAST and other related vulnerabilities) or to use TLS 1.1+ Note, that exploiting this flaw requires an active MITM attacker and a large number of carefully constructed requests to be sent by the client to the server, and a large number of TLS sessions. For example it was found that as much as 2^24 sessions may be needed to recover the first few bytes of plain text with "high probability". Another possible work around would be to list RC4 below other secure cipher suites when doing TLS handshake.
More references: Research paper: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf Vendors Patches: http://www.isg.rhul.ac.uk/tls/#Patches
Ivan Ristić's blog post which explains how Qualys SSL test currently rates RC4 compared to BEAST/CBC: https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
NSS lowered the priority of RC4 in cipher suite advertisement so that more secure ciphers instead of RC4 are likely to be chosen by the server. Reference: http://www.mozilla.org/security/announce/2013/mfsa2013-103.html https://developer.mozilla.org/en-US/docs/NSS/NSS_3.15.3_release_notes
Also NSS patch for comment #6: https://hg.mozilla.org/projects/nss/rev/9f313e08bd43
Further to comment #3 on this bug, this flaw exists with the inherent design of the RC4 algorithm and is therefore not specific to any implementation. Several research in cryptography has suggested making changes to RC4, but doing that would change the very algorithm used and is therefore not practical. A work around to this issue would be to lower the priority of RC4 in cipher suite advertisement so that more secure ciphers are likely to be chosen (similar to what NSS has done, as described in comment #6 and comment #7)
Statement: This flaw is related to the design of the RC4 protocol and not its implementation. More details and a possible work around is mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=921947#c8. Therefore there are no plans to correct this issue in Red Hat Enterprise Linux 5 and 6.