[Cryptography] Client certificates as a defense against MITM attacks

Nico Williams nico at cryptonector.com
Mon Mar 17 00:39:45 EDT 2014


This isn't new.  IIRC in
http://tools.ietf.org/html/draft-hartman-webauth-phishing-09 (but I
may be thinking of the wrong doc).  See the various versions and its
references.

Google's channel bound cookies basically do something like using user
certs for protecting session identifiers (cookies).  There's no MITM
detection, just protection against theft of cookies (e.g., possibly by
future MITMs, but also CRIME/BEAST type attacks).

In general one can use channel binding to detect MITMs when
authenticating at least the other peer to oneself.  Using channel
binding to detect MITMs when authenticating to the other side without
authenticating it back is harder.

The following is partly a restatement of what you say, really.

Q: Suppose you use a user cert in a TLS handshake, what do you know at
the end of the handshake (assuming it doesn't fail) beyond what you
would have known without having used a user certificate?

A: Only[*] that if there is an MITM they can't impersonate you
-specifically: your user cert's public key- to the real server!

That's nice, but not enough.

Now how will you know that the real server sees you as authenticated
to them and, therefore, that there was no MITM?  Well, suppose the
server is your bank, and you're looking at your bank account balances
and transaction logs: if you didn't authenticate to your bank but to
an active attacker then the attacker will have to know an awful lot
about you for you to realize that they're not your bank.  The attacker
might get to observe your intentions (e.g., move money about), but
they won't get to change your orders, and you'll eventually recognize
that something went wrong.

That's very nice, really -- not ideal, but much better than nothing.
You still have to enroll your public key at some point for this to
work... but we're making progress.  But there are some issues:

 - If you're going to use user certs this way, there'd better no be an
online password-based ("security question") login recovery procedure
that the MITM could trick you into using.  Otherwise there really
isn't any MITM protection from using user certs.

 - If the server is using a PKI to authenticate you (as opposed to
merely knowing your public key or a pre-shared cert for it) and you're
using a PKI to authenticate them... then two CAs (possibly one) will
be able to MITM you.  So it's important that the server know your key,
not just your name.

I.e., protection against MITM using client user certs is not trivial.

Actually, this reminds me of something...  We're updating SASL/GS2 to
relax some requirements so that OAuth, SAML-EC, and friends can be
used as GSS-API and SASL mechanisms.  The requirement relates to
channel binding and mutual authentication.  What this reminds me of is
that we probably should add security considerations text explaining
that channel binding can still provide a modicum of value (see above)
even when there is no mutual authentication.  (Note well: I'm using
"mutual authentication" in a sense that is a bit of a term of art that
is well understood on the IETF KITTEN WG mailing list.)

[*] That's assuming your private key remains secure and the TLS
protocol works as advertised.

Nico
--


More information about the cryptography mailing list