Re: safe renegotiation in client side

[Tomas Mraz]

On Thu, 2010-04-29 at 10:10 +0200, Simon Josefsson wrote: 
> Tomas Mraz <address@hidden> writes:
> 
> > On Mon, 2010-03-15 at 21:46 +0100, Nikos Mavrogiannopoulos wrote: 
> >> As you may have noticed there was a big fuss lately about a bug in the
> >> TLS protocol that could cause a client to connect to the wrong server
> >> via a renegotiation. There is a fix to the protocol that is
> >> unfortunately incompatible with previous versions (if security is
> >> required). Thus a gnutls client implementing the fix cannot connect to
> >> any non-patched server[0]. To achieve compatibility one has to to
> >> explicitly allow unsafe renegotiation with a priority string. This is
> >> not always possible since gnutls might be used unintentionally by a
> >> program via another library.
> >> 
> >> With some trials in my system I noticed that the current behavior causes
> >> denial of service and a simple user might not even have control over the
> >> priority string for gnutls.
> >> 
> >> Given your experiences (as system packager, user, implementor or so),
> >> what do you think is the adoption of priority strings in programs? Given
> >> a program that uses gnutls is it easy to set a string with the
> >> algorithms etc. needed for the negotiation?
> >
> > The OpenSSL upstream decided to allow the client to talk to the
> > unpatched servers by default. Of course it means that if the client
> > talks to such server it is vulnerable to the attack. They've also added
> > a function call so an application can query whether the connection is
> > protected by the safe renegotiation or not.
> 
> GnuTLS will behave the same.
> 
> > I, as maintainer of OpenSSL and gnutls packages in Fedora and Red Hat
> > Enterprise Linux, decided when backporting the safe renegotiation
> > patches to the old gnutls packages in released distributions, that the
> > client has to be tolerant to missing safe renegotiation support on
> > connected servers for now and so I have removed the strict client side
> > check from the backported patches. If the adoption of the safe
> > renegotiation extension gets better, we will release updated packages
> > which will contain the strict client side check.
> 
> What is your opinion on whether servers should refuse renegotiation
> attempts from clients that doesn't support the extension?

This is clear, they must refuse to renegotiate with them otherwise they
are clearly vulnerable. OpenSSL does the same. There probably should be
an option to allow it though. In case of OpenSSL it is the 
SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which is not enabled by default.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb