On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
> > There is no benefit in excluding RC4-SHA1 from the default list.
> > When servers support stronger algorithms, those will be negotiated.
> > All you get by exclusing RC4-SHA1 is loss of interoperability, which
> > may be OK for dedicated environments, but is not a good DEFAULT.
>
> Problem is that RC4 is providing comparable security to export grade suites.
> It is essentially broken.
The situation is not quite that dire, and the solution is not to
*remove* RC4 from the DEFAULT cipherlist (breaking interoperability),
but for servers to stop explicitly preferring it. OpenSSL has for a long
time placed RC4 *last* in the medium cipherlist, which is about right.
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
At the moment, the attack is not yet practical because it
requires access to millions and possibly billions of copies of
the same data encrypted using different keys. A browser would
have to make that many connections to a server to give the
attacker enough data. A possible exploitation path is to somehow
instrument the browser to make a large number of connections,
while a man in the middle is observing and recording the traffic.
The reason it is not last in practice is because some folks explicitly
raise its priority for performance reasons, out of habit, or because
of the various CBC attacks BEAST, CRIME, ...
To phase out RC4, encourage server operators to place it last in
their cipher-list (per the default cipherlist, which clearly many
of them are not using).
I am not arguing for continuing widespread use of RC4, I am arguing
against unnecessary incompatible changes in the DEFAULT cipherlist.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
