(The discussion of this topic is intended to be on the
[email protected] mailing list. This message has also been
cc'ed to the net-dev mailing list in an attempt to ensure that
interested parties are aware of it.)
RC4 is a 28 year old cipher that has done remarkably well, but it is
now the subject of several, significant attacks[1][2][3]. The IETF has
decided that RC4 is sufficiently bad to warrant a statement that it
must no longer be used[4].
When Chrome makes an HTTPS connection it has an implicit duty to do
what it can to ensure that the connection is secure. At this point,
the use of RC4 in an HTTPS connection is falling below that bar and
thus we plan to disable support for RC4 in a future Chrome release.
That release is likely to reach the stable channel around January or
February 2016. At that time, HTTPS servers that only support RC4 will
stop working.
Measurements show that only 0.13% of HTTPS connections made by Chrome
users (who have opted into statistics collection) currently use RC4.
Even then, affected server operators can very likely simply tweak
their configuration to enable a better cipher suite in order to ensure
continued operation. (Chrome has long implemented 1/n-1 record
splitting and is thus protected against the BEAST attack even with CBC
modes and TLS 1.0.)
Server operators who don’t wish to have to tweak configurations again
in the foreseeable future should check that they support TLS 1.2 with
ECDHE_RSA_WITH_AES_128_GCM and use the tool at
https://ssllabs.com/ssltest to find any other obvious problems.
Current versions of Chrome don't advertise support for RC4 on an HTTPS
connection unless the first connection attempt fails, so servers that
already support a non-RC4 cipher suite will not see any change.
AGL
[1]
http://www.isg.rhul.ac.uk/tls/ [2]
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/vanhoef [3]
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/garman [4]
https://tools.ietf.org/html/rfc7465 
