Re: [TLS] simplistic renego protection

[Michael D'Errico <[e-mail]>]

If a client doesn't check the server's certificate, it is subject to
any man-in-the-middle attack.  One of the requirements is that a client
verify the certificate.  If a client doesn't do that, how can we
possibly protect it???

I'm interested in providing the best defense to a client that is aware
of the MITM renegotiation problem when faced with having to interact
with possibly-unpatched servers.

Mike


Marsh Ray wrote:
> Michael D'Errico wrote:
>> The attack requires that there be a man-in-the-middle between the
>> client and server.  The MITM handshakes once with the server.  The
>> client then handshakes with the server via the MITM, so:
>>
>>   - the client sees the handshake as its initial handshake
>>   - the server sees the handshake as a renegotiation
>>
>> This is the point: the client is attacked on its *initial* handshake.
>>
>> Therefore the client needs to be protected on its *initial* handshake.
>>
>> It doesn't matter what happens after that.  If the client has completed
>> its initial handshake and there was no MITM, it is impossible for a MITM
>> to insert itself in the next handshake (i.e. a renegotiation).  So from
>> the client's point of view the only handshake it needs to be concerned
>> with (in terms of security not mechanics) is the initial one.
> 
> I hear this often enough that I don't argue with it every time,
> nevertheless...
> 
> There is another attack which is a mirror-image of this one, where the
> client sees a renegotiation but the server only sees one session.
> 
> One may dismiss this attack with the reasoning that "well it's the
> client's fault for not checking the cert at the right point". Perhaps
> for some specific protocol on TLS that may be true, but there doesn't
> appear to be anything the TLS protocol itself that requires clients to
> authenticate (rather than the other way round).
> 
> I strongly suspect many actual client applications are vulnerable to
> this attack.
> 
> For these reasons, I suggest that we are unsafe in concluding that all
> vulnerabilities can be fixed at the server.
> 
> - Marsh