Re: [TLS] simplistic renego protection

[David-Sarah Hopwood <[e-mail]>]

David-Sarah Hopwood wrote:
> 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.

Point of clarification: "strict server" here means that the server does
not accept *renegotiations* with an unpatched client. It still accepts
initial handshakes.

A "strict client", OTOH, will refuse to make even initial connections to
an unpatched server. So support for lenient (as well as strict) clients
is certainly necessary, but whether support for lenient servers is needed
is much less clear.

> 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