Re: [TLS] simplistic renego protection

[Marsh Ray <[e-mail]>]

Michael D'Errico wrote:
> If a client doesn't check the server's certificate, it is subject to
> any man-in-the-middle attack.

I was going to give the example of an anonymous server and an
authenticated client, but it seems prohibited by the spec: "Anonymous
servers cannot authenticate clients".

Nevertheless, it could be done with anonymous connections in which the
client retro-actively authenticates the server. One sees this kind of
thing in sample code all the time.

> One of the requirements is that a client
> verify the certificate.

Read closely:
>  If the server is authenticated,
>    its certificate message must provide a valid certificate chain
>    leading to an acceptable certificate authority.  Similarly,
>    authenticated clients must supply an acceptable certificate to the
>    server. Each party is responsible for verifying that the other's
>    certificate is valid and has not expired or been revoked.

It requires that the endpoints _validate_ the cert chain. I haven't
found where the spec says the certs have to be the right ones.

Indeed it seems that a common application error is to hand the TLS
library an open socket and let it validate whatever cert shows up from
the server. Another form of "authentication gap" perhaps?

> If a client doesn't do that, how can we
> possibly protect it???

By restoring the application-API guarantee that was lost when
renegotition was added to ssl: both ends know they are talking to the
same part during the entire connection, even if some of the sessions
have one or more anonymous endpoints.

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

Definitely. Also the best defense to patched servers talking to
unpatched clients, with or without renegotiation.

- Marsh