gnutls-devel
[Top][All Lists]
Advanced

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

Re: safe renegotiation bug?


From: Tomas Mraz
Subject: Re: safe renegotiation bug?
Date: Fri, 28 May 2010 10:05:26 +0200

On Fri, 2010-05-28 at 09:48 +0200, Simon Josefsson wrote: 
> Nikos Mavrogiannopoulos <address@hidden> 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

I've already argued about this before.

Although in case of connecting to a server which does not have the
renegotiation extension support the connection might be vulnerable. It
as well might not be in case the server has renegotiation support turned
off completely.

On the other hand if the client successfully renegotiates with such
server or the server requests renegotiation, the client now positively
knows that the connection is vulnerable.

So doing it like this seems to me as a reasonable compromise as there
might be reasons why implementing the renegotiation extension on some
legacy server was not feasible but it was possible to switch off the
renegotiations on it completely making it non-vulnerable to the attack.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb




reply via email to

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