Why is nobody using SSL client certificates? (2008)
pilif.github.io
pilif.github.io
There have been a number of TLS protocol issues regarding client certificates that didn't receive that much attention (Triple Handshake, SLOTH), because not that many people use clientcerts. That's not really an argument against them, but it's a hint that if we want to use them more widely things would probably need more scrunity in security analysis.
Another issue that worries me more: Client certificates can break privacy expectations. The reason is that the cert is not hidden from the traffic. This makes the traffic less privacy preserving than - let's say - a simple password, because the password is hidden inside the TLS encryption stream, while the client certificate is not. I think users have a reasonable expectation that "if I only surf HTTPS sites nobody sees any personally identifiable information from me, just the sites I'm surfing". Client certificates break this expectation.
However, what about self-signed certs?
They dropped the technology because no one savvy enough used the same computer long enough to be able to benefit from the feature more than a couple times. And you were still required to enter codes to match your forms with the administration's data, so it felt a bit useless even at the time.
You cannot expect them to have a certificate on them at all times except their ID card, and even that gets lost. And if they were to use their national ID card, as some do, they would need a smartcard reader. So with most computers looking like they do, that's yet another thing they need available.
Banking here in Sweden uses a setup similar to either PKI or 2FA, but the thing you have is usually a code generating device or your mobile phone. This is imo as good as it gets, since most people today have mobile phones. The code generating device becomes something you only use from your home when paying bills so that's out of the question for normal website authentication.
Another thing that was weird about the article is that it states client TLS certs as a 2FA method right after it says there would be no need for passwords. I fail to see the second factor in client certs if it's not a password.
With passwords or even many 2FA solutions, an attacker can just replay them to the server, and the server has no way to know that they're not coming directly from the client. But SSL client certificates cannot be replayed by the attacker, so if the server receives a valid connection with a SSL client certificate, it knows that it could only have come from a client with the corresponding private key.
There are proposals to also be able to authenticate the client in a non-replayable way with passwords (like TLS-SRP), but AFAIK they haven't been implemented in any browser.
I've been forced to use it in some scenarios as client and, although I found it a little bit confusing at first, it works; but my experience on the server... is just awful to implement.
If only it were standardized and widely supported.
I'd say that currently, it's actually worse. At least a cookie can be easily invalidated and regenerated, and typically expires after a relatively short time. Invalidating a cert is easy enough from the server side -- just stop accepting it. But how do you invalidate it and regenerate a new one on the client side? Well, currently, you ask the user to go into scary menus and do scary operations to delete the existing one. Then you can request the browser to generate a new one.
I think this is exactly the heart of the question that the article is asking. How do we make certificates a better form of authentication cookies?
Works fine for authentication. Usually the problems arise when you have to sign something, which usually requires a Java Applet. That's a real PITA.
Maybe if they use multiple computers, I could give them a certificate file that they could reupload to link the two computers as being for the same account. And a password might be available as a backup option.
It seems like there is some missing infrastructure, like if you drivers license had a chip with a key pair on it, I could see plugging it in to a card reader and having the browser send my signed identity certificate to the server. I guess credit card companies could do this too, i vaguely remember some sort of visa scanning device you could plug in to your computer for something like this in the 1990s.
One time, I automatically created 'accounts' for people based on their IP address on a toy project, because I didn't want to manage emails or passwords. It made it really convenient to use, but there's no way it would work as a permanent solution. I was imagining client certificates for a slightly more durable replacement, but for the same purpose.
Then again, OAuth logins seem to give something about as good so maybe this isn't necessary anymore. I never really bothers me to log in with Google.
We use them for device identification. It's ok in those scenarios. But for user auth, you really need smart cards to make it work.
This is pretty much analogous to what a website has to do when it uses a username/password for authentication.
> They need information on the key generation process.
While a useful documentation of sort can be provided by the website, I don't think having one visually different procedure per website will help the user
> 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).
We're talking about things that go outside the browser here. I think we all agree that giving access to the exterior to a website is easily dangerous
> They need a way to list the keys installed in a browser.
... only for the related website; I don't see why a website should be able to list other keys. Of course we could filter that with the browser... or just do it all from the browser anyway. Also, no website can do this for username/passwords
> They need to be able to add and remove keys (on the user's request).
Again, limited to the website, but here again there is no equivalent for passwords
And yes, of course in real life such features would be designed in such a way that the site can only access the entries relevant to itself. I do agree that the article was a bit loose in its language here. But why you would ever think that a standard would give more flexibility to certificates than it does cookies?
Cookies management, as seen from the user, is straightforward: there's a way to delete them all for a given site, and recently, thanks to the EU there's a banner telling him that there are cookies. The user can't do much more than that. Moreover, cookies are a crutch for the server to handle state.
Certificate management, on the other hand, is going to be a whole another animal, not only because there are much more things to handle, but also because we start dealing with crypto; moreover, we're talking about client certificates here, so IMO it should absolutely remain under the user control. I like to think that the website is a potential enemy (whether it wants to or not), and the browser is an ally so the less a website controls, the better.
This allows me to check on my server that there is no MITM between the user/device and the server. The user may be inclined to click "OK" and proceed anyway when there is such a warning, but my server will refuse in that case.
Also you should know that Apple use this for its push notification system.
But I still think the technology is underrated.
It's still a horrible situation, but has been made better for the general web thanks to the peoples at LetsEncrypt.
Client certificates can be used with multiple sites, do not need to be changed if one of the sites that you use gets cracked, can be revoked from if stolen, etc. Also they are typically stored encrypted, either on a smart card or encrypted in your browser, unlike cookies.
Some of these problems with cookies can be solved with a central authentication server (a trusted third party). In that case the central authentication server would generate an unique session cookie for each site, when the user logs in, and send the cookies to each of the sites. All communication still has to be encrypted in a way that prevents replay attacks.