Safe renegotiation patch

[Steve Dispensa]

On Jan 11, 2010, at 9:43 AM, Nikos Mavrogiannopoulos wrote:

> On Mon, Jan 11, 2010 at 3:46 PM, Steve Dispensa
> <dispensa at phonefactor.com> wrote:
>
>> All,
>>
>> I've updated the patch I initially submitted to conform to the new
>> renegotiation draft. It's building and working, and I'm starting
>> interoperability testing today. I hope to have something to post to  
>> the list
>> for review in the next day or two.
>> I wanted to run a couple of decisions by the group as to how this  
>> should
>> work. I've modified GNUTLS to always send (only) the RI extension  
>> for TLS1+,
>> and to send SCSV for SSLv3 initial client hellos. All other SSLv3  
>> hellos use
>> the extension, as required by the draft. Does that make sense? I'd  
>> be glad
>> to explain my reasoning if you'd like.
>
> Hello Steve,
> That sounds reasonable, however I am mostly concerned with the
> changes required to send the SCSV.

That part was fairly straightforward; the ugly part was getting it to  
send the RI extension for SSLv3 renegotiations.

> I had also ported yesterday your previous patch to git (with
> modifications - mostly error checking, priority string support and the
> new draft changes except for SCSV), so it would be nice to sync them.
> If you post your code I could merge both codes.

That would be great. My code has changed pretty significantly; I  
ported it to the head of 2.9, so it was reorganized a bit. The  
extension processing is also updated, since the draft changed a bit.

I'll try to get it cleaned up and sent over this evening. I believe  
it's about 800 lines.

>
>> Also, I'm providing three API's:

I meant two, of course. :-)

>> - gnutls_allow_unsafe_renegotiation - allows for "lenient" mode,  
>> where
>> we'll agree to talk to a peer that doesn't indicate support for safe
>> renegotiation
>
> Seems ok.
>
>> - gnutls_allow_unsafe_initial_negotiation - allows servers to talk  
>> to a
>> client that doesn't indicate support for safe renegotiation only as  
>> long as
>> the client doesn't attempt to renegotiate (but drops the connection  
>> on any
>> renegotiation attempt)
>
> Why this one is needed? Shouldn't all initial negotiations be accepted
> and fail only if renegotiation
> is requested? I believe this was the behavior of your previous patch.

A totally strict server may not want to allow unpatched clients, since  
those clients are unable to tell if they're being attacked. I  
defaulted it to off to be conservative from a security perspective.

>
> best regards,
> Nikos

-Steve