safe renegotiation bug?

[Nikos Mavrogiannopoulos]

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.
Safe renegotiation by default on server and unsafe on client[0].

Their flag SSL_RENEGOTIATE_REQUIRES_XTN is our SAFE_RENEGOTIATION flag.


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, and I believe that this is what
you documented in the manual[1] as well?


[0]. Disallows unsafe renegotiation in server sockets only, but allows
clients to continue to renegotiate with vulnerable servers. This value
should only be used during the transition period when few servers have
been upgraded.

[1]. The @code{%UNSAFE_RENEGOTIATION} priority string permits
(re-)handshakes even when the safe renegotiation extension was not
negotiated.