Another renegotiation patch

Simon Josefsson simon at
Thu Feb 18 13:32:30 CET 2010

Tomas Hoger <thoger at> writes:

> Hi Simon!
> On Thu, 18 Feb 2010 09:19:06 +0100 Simon Josefsson
> <simon at> wrote:
>> Steve, Nikos, are you happy with the safe renegotiation implementation
>> in git master now?  Do we have complete self-tests of this?  Is it
>> documented?  Has there been any interop testing with other
>> implementations?  Any other concerns I should be aware of?
> Few quick observations:

Thanks, this is really useful.

> - GnuTLS prefers RI to SCSV unless using SSL.3.0.  New OpenSSL (and
>   afaik NSS too) use SCSV in the initial client hellos even for TLS, to
>   play more nicely with broken TLS servers that choke on TLS
>   extensions.

GnuTLS advertises a >1.0 version by default, which breaks most of these
servers anyway.

> - gnutls-cli invoked with --disable-extensions still sends hello with
>   extensions.

This is actually an unrelated issue -- the parameter doesn't disable all
extensions even on 2.8.x.

> - gnutls-cli fails to connect to servers not implementing RFC 5746.
>   While this is required to fully address the issue on the client side,
>   it's likely to cause major issues in short term.  gnutls-cli(1)
>   suggests safe initial negotiation should not be required by default
>   to connect.
>   Note: Both OpenSSL and NSS will not require safe initial negotiation
>   yet for interoperability reasons.

Nikos, Steve, what do you think here?  My preference is to not reject
these servers, because the vulnerability exists theoretically in earlier
GnuTLS versions anyway but because of the GnuTLS API is different from
OpenSSL/NSS most if not all GnuTLS applications are not affected by this
(renegotiation will fail with the majority of GnuTLS applications).

> - %INITIAL_SAFE_RENEGOTIATION name is somewhat confusing (renegotiation
>   vs. negotiation).
> - %INITIAL_SAFE_RENEGOTIATION defaults are not documented properly (see
>   client concern above).
> - I'd consider clarifying %DISABLE_SAFE_RENEGOTIATION description too.

Maybe the terms could be more aligned with RFC 5746 terminology?


More information about the Gnutls-devel mailing list