[cryptography] Allergy for client certificates
iang at iang.org
Thu Oct 10 23:27:39 EDT 2013
On 9/10/13 01:41 AM, Tony Arcieri wrote:
> We use client certs extensively for S2S authentication where I work
> As for web browsers, client certs have a ton of problems:
I have successfully used them in a PHP website of my own design. I just
plugged away until they worked. I grant they have a ton of problems,
but it may be a case of half-empty or half-full. Here's my point by
point experiences, partly because the whole exercise for me was in order
to find out...
> 1) UX is *TERRIBLE*. Even if you you tell your browser to use a client
> cert for a given service, and you go back to that service again,
> browsers often don't remember and prompt you EVERY TIME to pick which
> cert to use from a giant list. If you have already authenticated against
> a service with a given client cert, and that service's public key hasn't
> changed, there's absolutely no reason to prompt the user every single
> time to pick the cert from all of the client certs they have installed.
Yes, that part doesn't work. So what my site did was to take every cert
provided and hook it up to the account in question. This was a major
headache to code up because I had to interpolate the contents of the
certs and do things like match email addresses.
It has a number of interesting edge cases such as correct name but
different email address. Also, the name isn't unique, or is it?
I solved these edge cases by leaning on CAcert's systems of governance,
and simply asking the user: "is this you?" If they lie, I can fall
back on Arb to solve everything. (OK, I cheated a bit there to get it
to work, there are other solutions and other possibilities, but I wanted
seamless non-support solution.)
> 2) HTML <keygen> tag workflow is crap and confusing. It involves
> instructing users to install the generated cert in their browser, which
> is weird and unfamiliar to begin with. Then what? There's no way to
> automatically direct users elsewhere, you have to leave a big list of
> instructions saying "Please install the cert, then after the cert is
> installed (how will the user know?) click this link to continue"
This is a problem that is outsourced from the website/user to the
CA/user interface. It can be done. I don't know how the coding is
done, but CAs do handle this well enough. I think again it is just a
matter of plugging away until you get the code going.
(What is not easy is using the certs for email. That's a fail, unless
you are using some form of automatic certs distribution.)
> 3) Key management UX is crap: where are my keys? That varies from
> browser to browser. Some implement their own certificate stores. Others
> use the system certificate store. How do I get to my keys? For client
> certs to replace passwords, browsers need common UI elements that make
> managing, exporting, and importing keys an easy process.
It is true that key management is crap, but how much do you care? As
long as the keys work, everything is cool ... for *users*. They never
need to look at keys. Only developers need that ... ;-)
(Yes, this is skipping the whole privacy question, but having worked
through it, you aren't going to do any worse with certs.)
> Passwords may be terrible, but they're familiar and people can actually
> use them to successfully log in. This is not the case for client certs.
> They're presently way too confusing for the average user to understand.
I think, if you can crack the "get a cert in the browser" problem, that
whole equation flips around. In my experience, client certs worked way
easier than passwords. They just worked.
The big benefit we had in our community was that our target audience
already had to have put their cert into their browser, it was part of
the Assurer test.
What was not easy is the websites. Taking random site X like a wiki and
engaging it for immediate auth with the cert is hard, mostly because
these systems out there have never really considered certs, and often
enough they haven't even considered SSL.
ps; More here:
More information about the cryptography