Re: [TLS] simplistic renego protection

[David-Sarah Hopwood <david-sarah at jacaranda.org>]

Nelson B Bolyard wrote:
> On 2009-11-19 11:05 PST, David-Sarah Hopwood wrote:
>> Nasko Oskov wrote:
> 
>>> If the MiTM sends a client hello to the server that has no extension, then
>>> the server has no way to drop the connection. This will require a strict
>>> server to prevent the attack and strict server config will not be reality
>>> for a long time. What am I missing?
>> That, in the RI approach, strict server config is essential from the start.
>>
>> We haven't yet established whether the ability to support lenient servers
>> is a requirement. Eric has argued against allowing that; so have I.
>> If lenient servers are allowed, then I think it will take *much* longer
>> until the vulnerability is eliminated from most connections.
> 
> I must have missed the message wherein "lenient server" was defined.

See my other followup.

> Is it a server that accepts client hellos without any signal that the
> client has been upgraded, but merely refuses to renegotiate with such a
> client?
> 
> IOW, is it the kind of server that numerous vendors are shipping now,
> that recent patches to open source have just created, one that refuses to
> renegotiate at all but still accepts old style client hellos?

No, those are strict servers.

>> Remember, rejecting a renegotiating ClientHello does not necessarily lead
>> to an interoperability failure; it only does so if the client will not
>> reconnect.
> 
> By definition, the alert that rejects a renegotiating client auth
> (no_renegotiation) is a warning alert.

Yes.

> It leaves the previous TLS
> connection and session state intact and able to continue.  So IINM, it does
> not lead to an interoperability failure unless the client chooses to treat
> that alert as fatal, despite being a warning, AND refuses to reconnect.
> Right?

Right, although if renegotiation is being used to tell the client to use
a client cert, then a client that continues with the connection will
probably receive an authorization error in the application protocol,
which is an interoperability failure if the client would have had the
needed cert.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

Attachment: signature.asc
Description: OpenPGP digital signature