Re: [TLS] simplistic renego protection

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

Nasko Oskov wrote:
> David-Sarah Hopwood wrote:
>> Martin Rex wrote:
>>> There are going to be components out there that will not get patched.  
>>> They might not implement renegotiation (or have it
>>> disabled) and they're therefore not even vulnerable.
>>>
>>> But we can not simply brick them (deny to talk SSL to them in the 
>>> future).
>>>
>>> So Browsers will likely have to continue to offer an fallback to 
>>> extension-less ClientHello.
>> 
>> This is a non-sequitur. Lenient clients don't need to send the extension in the
>> ClientHello of an initial handshake. Strict clients must not be able to talk to
>> unpatched servers, by definition.
> 
> I must be misunderstanding the attack. Why is the attack not possible
> even when client doesn't send the RI extension on initial handshake?

Because the server knows that the connection is a renegotiation from its
point of view, and therefore it rejects any handshake that doesn't
contain the extension.

> 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.

Remember, rejecting a renegotiating ClientHello does not necessarily lead
to an interoperability failure; it only does so if the client will not
reconnect.

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

Attachment: signature.asc
Description: OpenPGP digital signature