safe renegotiation bug?

[Tomas Mraz]

On Fri, 2010-05-28 at 09:48 +0200, Simon Josefsson wrote: 
> Nikos Mavrogiannopoulos <nmav at gnutls.org> 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: https://developer.mozilla.org/NSS_3.12.6_release_notes

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