On Mon, Mar 31, 2014 at 01:09:12PM +0000, Viktor Dukhovni wrote:
> 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).

What we really need are good defaults, and everybody using those
defaults instead of applications developers and administrators
overriding the defaults.

The default of apache is actually using the client preference,
as it was supposed to be doing.  But there are some reasons not to
use the client preference:
- Prefering different ciphers for performance reasons
- Prefering different ciphers because of their strenght
  This would allow you to select RC4 over 3DES if you
  care about IE on XP, or other things.
- Some clients don't have (EC)DHE first in their list,
  and you might want to use that if the client does.
  IE never sends those first, the rest does.

> I am not arguing for continuing widespread use of RC4, I am arguing
> against unnecessary incompatible changes in the DEFAULT cipherlist.

One could argue that having the export ciphers in the DEFAULT
means that you're willing to negiotate that cipher.  But I don't
find that a good idea and would like the connection to fail if
that's the only thing to other side supports.  I clearly don't
want to do a fall back unencrypted either.  So I would really
like to have LOW and EXPORT removed from DEFAULT.

RC4 is becoming close to what I think is unacceptable, but it's
still needed to talk to way too many things that I think it
should at this time still be part of the default.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to