[Pkg-openssl-devel] Bug#778747: Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used

[Kurt Roeckx]

On Sun, Feb 22, 2015 at 01:49:16AM +0100, Florian Schlichting wrote:
> On Fri, Feb 20, 2015 at 10:50:20PM +0100, Kurt Roeckx wrote:
> > On Fri, Feb 20, 2015 at 10:08:48PM +0100, Florian Schlichting wrote:
> > > | RC4                       377778    80.5871
> > > | RC4 Only                  3712      0.7918
> > > | RC4 Preferred             64613     13.7832
> > > | RC4 forced in TLS1.1+     41031     8.7527
> > > | x:FF 29 RC4 Only          541       0.1154
> > > | x:FF 29 RC4 Preferred     70622     15.065
> > > | x:FF 29 incompatible      136       0.029
> > > ...
> > 
> > One of the probloms is those servers that currently prefer/force RC4
> > if it's available.  That is administrators who have actually
> > configured things in such a way.  Removing RC4 from the default
> > will not fix any of them.  It's that 13.7% that is the problem.
> 
> For a client using DEFAULT, removing RC4 will "fix" their connections to
> exactly those 13.7% of servers. That's what this bug is trying to
> achieve. The cost is the 0.79% of servers where this change will lead to
> a handshake failure due to no common cipher being available any more.

I'm saying we should fix those 13.7% to instead not prefer RC4 but
have them use the default.  Removing RC4 in openssl's default will
not fix anything of those 13.7%.

Please note that openssl is ussually not used as a client for
https but as a server.  You should talk to the clients to have
them use something other than RC4 with those 13%.

For other services where openssl is used as both client and server
people have not screwed up the defaults because of BEAST because
BEAST is easy to exploit in https but not in other protocols.

> > Please note that RC4 in the default configuration should never be
> > negiotated by modern clients and servers.  The problem is
> > administrators who think they know better changed somethign not to
> > use the defaults.  If we adjust the defaults it's not going to fix
> > anything.
> 
> I disagree. A server that's still configured to use RC4-SHA:HIGH:!ADH as
> was initially recommended to mitigate the BEAST attack [0] will
> negotiate an RC4 cipher.

Please note the "default configuration".  That is not a default
configuration.

> If I use a client with an adjusted DEFAULT to
> connect to that server, RC4 will not be negotiated, and a better cipher
> will likely be used instead. So ill-adviced choices by administrators on
> remote systems _can_ be fixed by good defaults on Debian systems (within
> limits, of course).

Yes, and you should really talk to the browsers to fix their default.

> > I would like to point out that DEFAULT includes things like EXPORT
> > ciphers supporting 40 bit security, LOW including 56 bit security.
> > RC4 is still better then those and is currently in MEDIUM.
> 
> Why are these included in DEFAULT? Are you arguing that 40bit EXPORT
> ciphers are generally good enough to protect SSL/TLS sessions, in a
> world where we know there are third parties listening in on all
> long-range connections, and potential man-in-the-middle situations are
> commonplace for all wireless devices?

No, I'm saying DEFAULT is not what you think it is.  With TLS it
should be no problem to have those weak ciphers in the list, there
should be no way for a MITM to trick you into selecting one of
those if both sides support something better.  But it is of course
better to not actually list those as supported.

> So we're not talking about protecting default Debian Apache setups. And
> we're not talking about Debian users of Iceweasel or Chromium (which
> don't use OpenSSL). As I wrote before, I think we should be talking
> about the hundreds of applications that use openssl "for encryption",
> and rely on it to produce something sensibly secure, for 2015, 2018 and
> perhaps beyond.

Even with RC4 enabled on both sides, it does provide something
secure that doesn't use RC4 as long as you don't don't touch the
defaults.  And I've seen many applications that screw up the
defaults.

> RFC 7465 has been adopted for a reason. Let's take that seriously,
> please?

I do take it seriously.


Kurt