[TLS] Definition of "lenient server"

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

David-Sarah Hopwood wrote:
> Nelson B Bolyard wrote:
>> On 2009-11-19 11:20 PST, David-Sarah Hopwood wrote:
>>> 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.
>>> Point of clarification: "strict server" here means that the server does 
>>> not accept *renegotiations* with an unpatched client. It still accepts 
>>> initial handshakes.
>> If that is a "strict server", then what is a "lenient server"?
>> Is it a vulnerable server?
> 
> A server that does accept initial handshakes with an unpatched client
> (which obviously makes it vulnerable in that case).

Gack, sorry, typo.

A lenient server is a server that does accept *renegotiating* handshakes
with an unpatched client (which obviously makes it vulnerable in that case).

Both lenient and strict servers accept initial handshakes from any client.

I don't think there is ever a reason to reject initial handshakes where no
client certificate is used. There might be a reason to reject initial
handshakes where a client cert is used, in order to prevent the variant
of an attack where the client sees the renegotiation, and is unpatched.

> However, a lenient
> server, unlike an unpatched server, will detect an attack on connections
> with a patched client.

That is, on any connection with a patched client.

> I believe this is not enough to consider the server to have been "fixed",
> and I think it's a bad idea to end up with a subset of servers that
> appear to be patched, but are still vulnerable on some connections.

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