safe renegotiation bug?

Tomas Mraz tmraz at
Fri May 28 09:58:04 CEST 2010

On Fri, 2010-05-28 at 09:48 +0200, Simon Josefsson wrote: 
> Nikos Mavrogiannopoulos <nmav at> writes:
> > Simon Josefsson wrote:
> >
> >>>>> Should be ok now. I get aborts in the srn5 but they seem intended?
> >>>> I fixed that now -- however it seems there is another problem, now the
> >>>> rehandshake succeeds against a server that doesn't support safe
> >>>> renegotiation.  The second handshake in srn5 should fail, shouldn't it?
> >>> By default server is on unsafe renegotiation mode and doesn't require
> >>> any of the extensions, either on the first or subsequent negotiations.
> >>> Disallowing rengotiations after this point for the client shouldn't
> >>> offer any advantage since you are already connected securely to a peer.
> >> 
> >> But this self tests is with a server that has safe renegotiation
> >> disabled, see tests/safe-renegotiation/srn5.c.
> >> 
> >> 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:

Note that the same decision was made also by OpenSSL developers.
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

More information about the Gnutls-devel mailing list