Why is nobody using SSL client certificates?
Did you know that ever since the days of Netscape Navigator 3.0, there is a technology that allows you to
- securely sign on without using passwords
- allow for non-annoying two-factor authentication
- uniquely identify yourself to third-party websites without giving the second party any account information
All of this can be done using SSL client certificates.
You know: Whenever you visit an SSL protected page, what usually happens is that your browser checks the identity of the remote site by checking their certificate. But what also could happen is that the remote site could check your identity using a previously issued certificate.
This is called SSL client side certificate.
Sites can make the browser generate a keypair for you. Then they'll sign your public key using their private key and they'll be able to securely identify you from then on.
The certificate is stored in the browser itself and your browser will send it to any (SSL protected) site requesting it. The site in turn could then identify you as the owner of the private key associated to the presented certificate (provided the key wasn't generated on a pre-patch Debian installation *sigh*).
The keypair is bound to the machine it was generated on, though it can be exported and re-imported on a different machine.
It solves our introductory three problems like this:
- by presenting the certificate, the origin server can identify you. No need to enter a user name or a password.
- By asking for a password (something you know) and comparing the SSL certificate (something you have), you get cheap and easy two factor authentication that's a lot more secure than asking for your mothers maiden name.
- If the requesting party in a three-site scenario knows your public key and uses that to request information from a requested party, you, can revoke access by this key at any time without any of the parties knowing your username and password.
Looks very nice, doesn't it?
So why isn't it used more often (read: at all)?
This is why:
The screenshot shows what's needed to actually have a look at the client side certificates installed in your browser, which currently is the only way of accessing them. Let's say you want to copy a keypair from one machine to another. You'll have to:
- Open the preferences (many people are afraid of even that)
- Select Advanced (scary)
- Click Encryption (encry... what?)
- Click "View Certificates" (what do the other buttons do? oops! Another dialog?)
- Select your certificate (which one?) and click "Export" (huh?)
Even generation of the key is done in-browser without feedback by the site requesting the key.
This is like basic authentication (nobody uses this one) vs. forms based authentication (which is what everybody uses): It's non-themeable, scary, modal and complicated.
What we need for client side certificates to become useful is a way for sites to get more access to the functionality than they currently do: They need information on the key generation process. They should allow the user to export the key and to re-import it (just spawning two file dialogs should suffice - of course the key must not be transmitted to the site in the process). They need a way to list the keys installed in a browser. They need to be able to add and remove keys (on the user's request).
In the current state, this excellent idea is rendered completely useless by the awful usability and the completely detached nature: This is a browser feature. It's browser dependent without a way for the sites to control it - to guide users through steps.
For this to work, sites need more control.
Without giving them access to your keys.
May 27th, 2008 - 01:45
It is because:
1. They’re difficult to manage at scale
2. Malware actively steals them
3. They not really “something you have”, just another ”
something you know”.
May 27th, 2008 - 08:43
I’m not sure about some of your points:
1) Managability:
on the server side, I don’t see how it’s harder to manage the issued certificates than it is to manage passwords. On the client side, I agree with you: The certificates are a pain to manage, but this is where my article was leading to anyways: We need a better UI to manage them.
2) Stealing:
Malware is also actively stealing passwords (just look at the MMO account hacking going on all over the place). If the certificate store was encrypted using a master password that needs to be entered once per session, stealing becomes harder.
3) I think nobody actually /knows/ their private key. It’s a binary blob you can move around from machine to machine, but it’s not something you know. I agree though that it’s not as secure as, say, some token generator, but that wasn’t what I compared it with in my article. I compared it to questions about your maidens name.
Philip
July 25th, 2008 - 07:03
Here’s another problem (which adds to the complexity!).
A common mechanism used by servers to create client certificates is, I believe, to capture user id info via a form, then the server form handler cgi uses (say) openssl utilities to generate a client key and a client certificate request. Then the cert is signed and bundled with the client key (pkcs12?) and returned to the client’s browser with some(?) MIME type that causes the browser to import the client key and cert.
My objection is that my private key is generated by some remote server! I appreciate that this is done to avoid burdening users with details of ssl key generation and cert request creation, and I do not have a solution — but this does kinda annoy me that to get a client cert I have to trust the server more than necessary. As an example of abuse, the server could generate bogus transactions of some sort (from another copy of the key & cert) and argue that the cert-login implies non-repudiability.
Perhaps I’m mistaken about common practice and the key may be generated in the browser (maybe for IE/active-X?), but that is still disturbing because the key is generated by an agent that I can’t examine. Private keys should be totally under _my_ control, eh?
Regards,
..jim
July 25th, 2008 - 10:39
both IE and Mozilla contain functionality to generate the private key on the client. Only the public key is ever transmitted to the server and signed there.
Philip
November 19th, 2008 - 01:23
Good luck stealing an SSL key from a secure token, malware.