[Cryptography] On the deployment of client-side certs

[Tony Arcieri]

On Mon, Nov 14, 2016 at 2:45 PM, Ray Dillinger <bear at sonic.net> wrote:

> Predictably we still have massive fraud perpetrated through credential
> theft followed by use of stolen credentials as an unauthenticated client.
> [...]
>
> There is a technical standard for client-side certificates, which was part
> of the original SSL specification.


Browsers are (I think quite clearly?) the main use case, but the existing
client cert implementation and UX in browsers is rather suboptimal. Browser
vendors seem to be reluctant to even support it, and are looking at phasing
parts of it out (e.g. the <keygen> tag) since it's so infrequently used.

The main problem is in the current incarnation, client certs are a
same-origin policy violation: one cert can potentially be used on many
sites. This means:

1) We don't automatically know what client cert to use to authenticate a
user. This means we have to ASK the user which cert to use. Often browsers
don't remember
2) Since certs can be used across origins, they leak a linkable identity
across sites

What's needed to solve these issues is a system which provisions unique
"certificates" per site (i.e. origin-bound certificates). Our best bet
there is Token Binding, which is implemented as a TLS extension and HTTP
header, which is being standardized through the IETF (with Google doing
most of the design/implementation work):

http://www.browserauth.net/token-binding

I believe they're in the process of wrapping up their work. I saw they just
open sourced an implementation as well:

https://github.com/google/token_bind

All that said, I think client certs are fantastic for server-to-server
authentication, but something like token binding seems like a better fit
for end users, IMO.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161114/fcea1a18/attachment.html>