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.
<divpInteresting problem. Isn’t it?</p>
gnegg 