safe renegotiation bug?
Simon Josefsson
simon at josefsson.org
Tue Jun 1 11:10:48 CEST 2010
Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> Simon Josefsson wrote:
>
>>> 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?
>
> As a concept I agree... The only problem might be that
> %PARTIAL_RENEGOTIATION might be misleading in client side because it
> doesn't really protect from the https renegotiation attack, but this can
> be made clear in the documentation. I'll try to check it today.
Right, PARTIAL_RENEGOTIATION is the trade-off approach that is
vulnerable to some attacks but at least allows interop to happen. I
think we have some good warning material in the manual already for this.
It would be great if you could make modifications to make this happen.
I can update the self tests to make sure it is working as we want it to.
Alas I'll be travelling in the next few days, but I'll have some
connectivity and can do a 2.9.11 release.
/Simon
More information about the Gnutls-devel
mailing list