[Cryptography] Client certificates as a defense against MITM attacks

Christian Huitema huitema at huitema.net
Sun Mar 16 14:58:20 EDT 2014


> This doesn't solve the "first connection between a pair of parties neither
of whom has any way of identifying the other".  Sure, you might as well
allow the user to send a cert registered with some CA.  Someone in the
middle who can "open up" the SSL session being initiated can just replace
that with their own cert, and now there's no basis for trusting the the
client cert is actually bound to the user.  It seems we always end up back
at "key continuity" as the best we can do - which in the "parties initially
unknown to each other" setting seems unavoidable.
>
> Am I missing something obvious here?

This comes down to "detecting MITM." You could indeed use client
certificates. You could also use some form of password check that is secure
against MITM, e.g. EKE. But the client authentication tends to happen
outside of the TLS exchange, because it is a somewhat complex user
interaction. What if this is the first time the client connects to the site?
What if they just start using a new device? What if they forgot their
password? If client authentication is implemented outside the TLS exchange,
what API do we have to tie the client verification to the TLS credentials
and negotiated keys?

Detection inside the second automated TLS exchange could also rely on
"re-negotiation." If the MITM attack does not happen all the time, it will
lead to renegotiation failure, and that can be detected.

-- Christian Huitema





More information about the cryptography mailing list