[Cryptography] Client certificates as a defense against MITM attacks

[Jerry Leichter]

On Mar 17, 2014, at 8:43 AM, Thierry Moreau <thierry.moreau at connotech.com> wrote:
>> Am I missing something obvious here?
> 
> Maybe you merely (re-)invented the HTML cookie holding the client private key.
An HTML cookie isn't bound to the end-to-end connection context.  A MITM simply passes it through.  The signed information I'm suggesting the client send *is* bound to that context, and isn't subject to this trivial vulnerability.

One relatively non-intrusive way to introduce this, in fact, might be to allow for "dynamic cookies":  Cookies whose content is computed inside the browser.  (This parallels the transition from the original view of servers sending the contents of static files to servers sending content that's created on the fly.)  If the HTTP client cookie contained a value computed from the end-point connection information, a MITM who merely passed it along would reveal its presence; but it couldn't compute a credible replacement with the client's private key.  (In fact, since the cookie will be passed along with every request, you might as well compute it based on the full end-point connection history.  Then, if anyone somehow slips a message into the stream and gets the client to accept it, the server will know as soon as it receives the next request.  The real problem here is that the party that really needs to know this is the *client*, and there's no way for the server to send back a message that the client can rely on seeing.  Perhaps using an out-of-band channel is what's needed - if the server sees a problem, it sends you a text message.)

> More or less explicitly, the "first party certification paradigm" seems attractive to you: no CA-in-the-loop for server trust in client public keys.
Absolutely.  We knew CA's were a weak link - one that was getting weaker - even before Snowdownia.

CA's (and PKI) remain the only solution proposed for the "how do I form a trustworthy connection to amazon.com if I've never been there before."  We need to do everything we can to strengthen them in that role.  (Certificate pinning, various means for checking the history and visibility of their certs, securing DNS, etc.)  But they inherently remain centers of trust that are not and cannot be trustworthy in general public usage.  Wherever we don't absolutely need them, we should avoid relying on them.

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140317/f5eb07b9/attachment.bin>