Re: [TLS] simplistic renego protection

[Marsh Ray <[e-mail]>]

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