Bug 921947 (CVE-2013-2566) - CVE-2013-2566 SSL/TLS: Attack against RC4 stream cipher
Summary: CVE-2013-2566 SSL/TLS: Attack against RC4 stream cipher
Alias: CVE-2013-2566
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
Blocks: 921950
TreeView+ depends on / blocked
Reported: 2013-03-15 10:18 UTC by Huzaifa S. Sidhpurwala
Modified: 2021-02-17 07:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-09-17 06:53:13 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 359523 0 None None None Never

Description Huzaifa S. Sidhpurwala 2013-03-15 10:18:55 UTC
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.



Comment 1 Tomas Hoger 2013-03-15 14:12:29 UTC

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.


Comment 3 Huzaifa S. Sidhpurwala 2013-06-17 06:32:27 UTC
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.

Comment 4 Huzaifa S. Sidhpurwala 2013-07-09 03:00:31 UTC
More references:

Research paper: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf
Vendors Patches: http://www.isg.rhul.ac.uk/tls/#Patches

Comment 5 Tomas Hoger 2013-08-01 07:51:16 UTC
Ivan Ristić's blog post which explains how Qualys SSL test currently rates RC4 compared to BEAST/CBC:

Comment 6 Huzaifa S. Sidhpurwala 2013-11-19 05:29:17 UTC
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.



Comment 7 Huzaifa S. Sidhpurwala 2013-11-19 06:28:02 UTC
Also NSS patch for comment #6:

Comment 8 Huzaifa S. Sidhpurwala 2013-12-05 06:05:20 UTC
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)

Comment 9 Huzaifa S. Sidhpurwala 2013-12-05 06:07:10 UTC

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.

Note You need to log in before you can comment on or make changes to this bug.