gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: safe renegotiation bug?


From: Simon Josefsson
Subject: Re: safe renegotiation bug?
Date: Mon, 31 May 2010 19:54:40 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Nikos Mavrogiannopoulos <address@hidden> writes:

> Simon Josefsson wrote:
>
>>>> The client by default permits connections, but I don't think clients
>>>> should (by default) allow renegotiation against such servers.
>>> Why?
>> 
>> To me it was more that I couldn't answer 'Why not?'.  I'm not sure what
>> the balance should be.  We already decided that (by default) we can't
>> disable everything we know is insecure due to interop, so decisions
>> whether to enable/disable other things by default is subjective.
>> 
>> NSS does not allow upgraded clients to renegotiate with unupgraded
>> servers, see: https://developer.mozilla.org/NSS_3.12.6_release_notes
>
> Simon,
>  Actually this is not what I understand from their release notes. Their
> transitional flag (SSL_RENEGOTIATE_TRANSITIONAL) does what we do now.

But it is not NSS's default behaviour.

> Safe renegotiation by default on server and unsafe on client[0].
>
> Their flag SSL_RENEGOTIATE_REQUIRES_XTN is our SAFE_RENEGOTIATION flag.

I think it is SAFE_RENEGOTIATION + INITIAL_SAFE_RENEGOTIATION.

> Moreover by thinking it, I believe that the behavior of
> %UNSAFE_RENEGOTIATION to the client, that you check with srn5 is
> correct. It should have allowed the client to renegotiate. This is its
> purpose, compatibility with old servers,

The client in srn5 uses the default settings.  Permitting clients to
rehandshake without safe renegotiation seems like a bad idea to me --
then the client _knows_ it may be talking to an attacker.  That is a
default-unsafe behaviour, and there is no significant interop issue to
consider for rehandshakes.

> and I believe that this is what you documented in the manual[1] as
> well?

No -- the manual says:

  GnuTLS supports the safe renegotiation extension.  The default
  behavior is as follows.  Clients will attempt to negotiate the safe
  renegotiation extension when talking to servers.  Servers will accept
  the extension when presented by clients.  Clients and servers will
  permit an initial handshake to complete even when the other side does
  not support the safe renegotiation extension.  Clients and servers
  will refuse renegotiation attempts when the extension has not been
  negotiated.

I don't think that is (especially last sentence) what is implemented
now.  I would prefer to implement what is described in that text
(because it seems to make sense to me), but we could change the text to
match what is implemented (more relaxed approach).

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]