[Cryptography] Client certificates as a defense against MITM attacks

[Ben Laurie]

On 16 March 2014 13:56, Jerry Leichter <leichter at lrw.com> wrote:
> SSL was designed primarily - and is used almost exclusively - under a model in which servers are considered trustworthy while clients were not. Thus, we have server-side certificates that clients rely on, but everything about server trust of clients is ad hoc.
>
> But we're in a different world.  DNS can't be trusted; CA's can't be trusted; browser lists of who *can* be trusted among CA's are a joke.  MITM attacks - the thing we built the entire structure to block - are commonplace.  There's are many "legitimate" corporations selling wares to make this easy, and we know there have been legal attempts to get hold of server keys (so there have almost certainly been "black bag" jobs to do the same thing).
>
> So let's expand the model a bit.  Imagine clients have certs, too, and that servers know their client's certs.  If, once an SSL connection was established, the client sent a message, signed with its own cert, saying "This is the SSL hash of the CA that signed the cert I used for you and the session key I'm using to talk to you", the server could immediately detect any MITM attack.  We can think about what to do from there, but fundamentally if it's concerned about its user's security, it must shut the connection down.
>
> An attacker could still completely impersonate a site; and a site might be compelled to consider the connection OK anyway; or the client's cert might be tampered with.  But any of these is much more intrusive and visible than simply tapping in, and doing stuff on the client side requires a hugely larger scale of operation.
>
> Where does the client's cert come from, and how does the server authenticate it?  I'd suggest that you get most of the way there by having the server generate the cert for the user and save it on his browser when his session is created and the first time he connects from a given browser - that is, pretty much the same way as the username and some kind of "this computer has been used by this user before" cookies are now commonly set. This way, the server actually knows the user's public key; it doesn't need to rely on a CA, even an internal one.  (The server should destroy the client's private key once it's been sent.)  Yes, that data could be grabbed, legally or otherwise, but there's more of it and it's not one fixed piece of data for all time - it keeps growing.
>
> 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?

http://tools.ietf.org/html/draft-balfanz-tls-channelid-01