česky | english
Client Certificates and SSO - The Old-New Thing
Iang gave a Lightning Talk at Fosdem 2010 entitled "Client Certificates, the old-new thing". Here are some notes that went with the talk. See also the Slides at ODP source and PDF output. youTube has video. Also given at LCA2011.
This is a story about Authentication. We started out in say the 1980s with everyone being trusted, but this quickly switched to passwords and usernames. In the 1990s, the buzz was all about Single Sign On or SSO, and then in the 2000s we hear about Federation.
Why didn't it work? Why are we still trying to solve this problem? Well, "everyone trusted" didn't work because not everyone is worthy of trust. Usernames and passwords suffered from an explosion: every person had many different sites, all with their passwords to remember. With too many passwords, re-use, simplicity and complexity made for a heady mix, and the resultant problems caused user and support costs ... not to mention, security.
SSO suffered another problem: every site had to choose a method, but so did all the users. Sites looked at all the members who hadn't chosen their favourite method, users looked at all the sites that weren't adopting their preference. This is a deadly embrace better known as chicken & egg problem.
Federation also suffered the complaint that users didn't want their data at some corporation site, and companies didn't want their customers tracked that way either. Suspicion was an issue.
We know how to do the Basic story of authentication in theory, but we've failed the practical exam. Why can't our computers do this?
Well, it turns out they can: there is in every browser and every webserver a thing called client certificates. These are good old cryptographic tools. Simply put, a public-private key pair where the public key has a signature slapped on the end, generally from some other party like a CA. Why didn't they work?
Looking at the above selection of failures, it wasn't (a) because it is all in the webserver software like Apache or IIS and has been there for a long time. Also, data protection issues didn't really rise up (although they exist) because the data in the cert itself isn't enough to matter so much, and its use is probably controlled well enough.
It is (b): most users did not have a client cert. Why? Well, it was too complicated, far too complicated for ordinary users, and this put a drag on the whole evolution. It was the failure of the egg, so the chickens never grew. Really, why this didn't happen is best answered by this: "don't ask." You'll be happier with this answer.
This is the story of how CAcert solved this problem. And, it is a bit of a story, as we'll see.
Certificates from CAs are something to do with "Identity," whatever that is, and we find that out by what we call Assurance. In CAcert we had around 8000 Assurers who did this process of individually checking the "Identity" of other members. Some call this the web of trust .
CAcert had the big problem of getting an audit, and that led to a big question: how do you audit a web of trust ? Classically, audits expect doco, standards, verification. So CAcert did this, and one element of this was the by now famous Assurer Challenge on the CATS system. 25 multiple choice questions wrapped up into a basic PHP website, so far not complex.
It was here however that we had an inspiration: we decided that the only way to access this was via Client Certificates. Was this because we are a CA, or we wanted to be cool, or because we think 25 multiple choice questions, downloadable off the net, need to be treated with high security protection? Or? Perhaps this was one of those "don't ask" questions, or perhaps we wanted this story to be told?
Either way, it worked. CATS went live early 2008, and became compulsory early 2009. From those nearly 10k assurers, our numbers dipped down dramatically, and gradually climbed back to the present day number of 3,339 (today?). Our current base of Assurers is far stronger, for more capable and recent events bear testimony to that.
This then allowed us to get into the Chicken business. Now that we knew that every one of our Assurers had a client certificate in their browser, we could insist that every one of our websites use client certificates. So we did: first with the blog, also with Sympa and the board's voting tool. It's an ongoing task, a priority for the applications people to do this.
How well did it work? Very well. For the blog, we enabled new and more authors because they just need a client certificate; they don't need to ask permission, and be told no or lost or ignored. Lost passwords are no longer an issue. Spam is solved.
There are some Gotchas, all is not perfect. Firefox gets confused with multiple certificates, for this we are waiting on white listing to be added by the Firefox development team. Also, when Apache decides it doesn't like the client certificate, it sends an SSL connection protocol error back to the browser. Which displays this to the user. This is wrong, the client needs to be told to check their client certificate. Unfortunately, this is a bit of developer hubris, with both sides saying they are doing the right thing, and blaming the others rather than fixing the problem. This problem will likely resolve when the weight of user complaints forces some more open thinking.
Strategies. We now know enough to suggest how client certificates be deployed. The first question is whether you mix passwords and client certs, allowing users to pick. There are some downsides: It means that there is a gap between the methods, so you'll be forever coding in that area, forever dealing with support and bugs. This is the same gap as between HTTP and HTTPS, which is exploited by phishing. CAcert uses this hybrid method on its website, but only because it also has to permit users to recover their account somehow.
Then there is going solo: Only SSL, only client certificates, all the time, every time. This is far better because there are no exceptions to code up (landing page bug), no dirty code cases to deal with (has she, hasn't she?). Then we have the question of doing the certificate processing in Apache or in PHP (or other code). The (2.a) former allows some string processing, but it tends to be too much or too little, there are always some cases that are better dealt with in code. So, best to do the whole lot in the PHP application code (2.b).
In more depth, a third Gotcha is that client certificates do change: they expire, and they can be lost or compromised. Here, in your PHP code what you can do is store the client cert information in the database, and index from that to the account. When a new certificate turns up, you can scan for the email address or the Name, and rely on that being equivalent. This gives a much smoother experience for the user, although more thinking is required if the Name and email address changes, or there are collisions in Names.
Conclusion. For us, client certificates worked and worked well. They save our administrators time, they make our users happy because the access is far simpler and more reliable than over username/password. They solve the SSO problem for us, and they work ... as long you can get the users their egg.
And, that is the challenge for you: How to get client certs to your users, so you can then benefit. 3 possible strategies are: Like CAcert did, build a site, any site, and insist on client certs. Pull your users into it. Next, Push your users by simply stating a rule like "All users are also CAcert Assurers." (This is something I have done with another technical foundation I am involved in.) Finally, you can create a simple internal CA and do "factory issuance" of client certs to your people.
Thanks, and questions.
- what about TLS-renegotiation?
- answer: Beyond scope really, but if you limit your website to using only client certs all the time (get rid of any subdirectory .htaccess files) then I gather that renegotiation isn't triggered.
- Is there a privacy issue?
- answer: yes, fundamentally any site can request your certificate in a client cert TLS session, which means that sites can see your name without you realising. A bug is filed at Mozilla over this ... again we are waiting on better control of certs in Firefox (with whitelisting). Also note that the server request for client-cert is a fundamental weakness or bug in the TLS protocol, and that isn't likely to change, so the browser will have much more work to do, and servers will always need to be configured.