safe renegotiation bug?
simon at josefsson.org
Tue Jun 1 09:08:45 CEST 2010
Nikos Mavrogiannopoulos <nmav at gnutls.org> 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
%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
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?
More information about the Gnutls-devel