Re: safe renegotiation bug?

[Simon Josefsson]

Nikos Mavrogiannopoulos <address@hidden> writes:

> Simon Josefsson wrote:
>
>> Then there is no way to make clients allow initial handshakes but
>> disallow renegotiations.  That goes against a RECOMMENDED in RFC 5746:
>> 
>> 4.2.  Client Behavior: Legacy (Insecure) Renegotiation
>> 
>>    This text applies if the connection's "secure_renegotiation" flag is
>>    set to FALSE.
>> 
>>    It is possible that un-upgraded servers will request that the client
>>    renegotiate.  It is RECOMMENDED that clients refuse this
>>    renegotiation request.  Clients that do so MUST respond to such
>>    requests with a "no_renegotiation" alert (RFC 5246 requires this
>>    alert to be at the "warning" level).  It is possible that the
>>    apparently un-upgraded server is in fact an attacker who is then
>>    allowing the client to renegotiate with a different, legitimate,
>>    upgraded server.  If clients nevertheless choose to renegotiate, they
>>    MUST behave as described below.
>> 
>> I would prefer a good reason to do something like that.
>> 
>> I don't understand your "because it allows clients to have a maximum
>> compatibility when %UNSAFE_RENEGOTIATION is specified".  Changing the
>> _default_ behaviour to follow the RFCs recommendation would not change
>> what happens when %UNSAFE_RENEGOTIATION is specified.  And indeed, with
>> %UNSAFE_RENEGOTIATION clients do have maximum compatibility already.
>> Could you clarify what you meant here?
>
> I mean that the default now for the client is %UNSAFE_RENEGOTIATION. As
> far as I understand what you propose is to add an extra level for the
> client that allows initial negotiation but not subsequent ones. Am I right?

Almost -- I want the default to disallow unsafe re-handshakes both in
client and server.  That would not be equal to %UNSAFE_RENEGOTIATION
(which is more relaxed) or %SAFE_RENEGOTIATION (which is more
conservative).  If we need a priority string for this middle road, we
can call it %PARTIAL_RENEGOTIATION.

> To be honest I'd prefer to modify unsafe renegotiation to do what you
> propose rather than adding an extra level. The code getting more and
> more complicated as well as the behavior. It might be better to have few
> easily explained states, rather than a bunch. With this change clients
> using gnutls would need to specify %DISABLE_SAFE_RENEGOTIATION to have
> the compatibility behavior (which is not so good but one has to draw a
> line somewhere between keeping things simple and supporting everything).
>
> So which solution do you prefer?

I'm not sure that is a good idea -- then there is no way to configure
mod_gnutls to talk to anyone.  People would need to use an older GnuTLS,
or install mod_ssl or mod_nss instead to get that behaviour.

However, we already have %INITIAL_SAFE_RENEGOTIATION so we already have
four different priority strings.  I think we could be feature complete
with four different priority strings if we redesign things slightly:

%DISABLE_SAFE_RENEGOTIATION: Disable the extension, permits unsafe
 (re-)handshakes.

%SAFE_RENEGOTIATION: Enable extension and require it for all handshakes.

%PARTIAL_RENEGOTIATION: Enable extension and require it on all
 re-handshakes but permit initial handshakes without it.

%UNSAFE_RENEGOTIATION: Enable extension and permit all (re-)handshakes
 without extension.

The default for both clients and servers would be
%PARTIAL_RENEGOTIATION.  We'll change the defaults to
%SAFE_RENEGOTIATION in two years or so.

What do you think about this approach?

/Simon