There's one thing about client certs that people should be aware: They open up new security and privacy issues.
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.
In TLSv1.3 the privacy issue is fixed. The client certificate is sent encrypted. And also, the client certificate doesn't have to be sent in the beginning of the session.
We used to use client certificates to declare and pay our taxes online in France, about a decade ago.
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.
Spot on, this is the problem when you're dealing with the general public.
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.
Would it be so crazy to have a standard javascript API that websites could use to store or remove certificates from the browser? With user validation of course.
There are browser-side APIs to generate key pairs, but there is no real standard as the KEYGEN tag is not widely supported, so on the server side you need to implement virtually one method per browser type you are addressing. And then you want to store your private keys somewhere safe, which is implemented differently by OS/browser. Some browsers use the system keystore for storage, others like Firefox have their own implementation (NSS). We are not lacking implementations here, merely browser standards.
To answer your question: I do not think startssl supports local key generation for all OS/browser combinations, they probably (painfully) hardcoded the most common ones.
It's interesting too that KEYGEN is now listed in the WHATWG spec as deprecated. Apparently what little interest there was in trying to standardize this has already somewhat fizzled out.
FWIW, keygen's deprecation isn't a rejection of client-side encryption: it's a rejection of the design of the keygen feature to address those requirements.
I was curious about that, and that seems a fair reason, but it doesn't show much interest in client-side encryption if it has been rejected without favoring some new proposal.
There's another advantage to SSL client certificates that this article doesn't mention: it allows the server to know that the connection isn't being intercepted by an attacker.
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.
No, not really. Server needs to trust that client would reject an invalid or
forged certificate. Diffie-Hellman key exchange is still a subject to
man-in-the-middle attack.
Is not just the UX of using the client certificate in the browser, there's also the problem in the server: maintaining a CRL (Certificate Revocation List), or using OCSP (Online Certificate Status Protocol).
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.
I think a more sensible approach should be similar to `authorized_keys` with `ssh`, where the server keeps a list of public keys for each user, and challenges the user to prove he/she has the corresponding private key for authentication. TLS certificates are notoriously complicated. It may be necessary for server certificates, because the "trust the key on the first connection" is probably insecure when money is at stake, but I don't see any advantages of client certificates over the ssh scheme.
If only it were standardized and widely supported.
Part of the problem with this approach is that it uses one single system to represent a number of claims about the client that should actually be treated separately. Identifying a user (who has history on a site) is different from identifying a hardware device, or a particular browser instance. Without knowing which particular claim the certificate is presenting it is hard to know how much to trust it. Just building a GUI does not solve this problem, and usage could create a false sense of security. If a machine is compromised is a client cert really any better than a cookie?
> If a machine is compromised is a client cert really any better than a cookie?
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?
Spanish Tax Agency and Social Security both use SSL client certificates to authenticate citizens, and I guess that's also true for other countries with smart cards as national id cards.
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.
A lot of the internal systems where I work use mutual SSL authentication instead of hard coding user accounts into API requests, it took some setting up between the various parts of the business but it's made shifting information around securely a much simpler process. I'm not sure of how beneficial this would be for most everyday computer users, given the relative complexity getting it set up and lack of widespread knowledge about the technology and processes behind how it works, many users can grasp username+password but might struggle with SSL.
If I needed a client certificate to view my webmail it would be quite cumbersome to check my mail while borrowing a friend’s computer. A password is portable.
On mobile clients they can be quite convenient though. No need to remember any password and good protection against shoulder-surfing.
Relevant: https://www.youtube.com/watch?v=ybNWOhI-Q-4
This sounds like a great idea. Is there a Ruby gem for Rails that would allow me to automatically create accounts for users when they visit my site, provision certificates for them, and log them in each time they visit?
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.
So you would manage their keys for them? It helps overcome the technical issues of creating keys but it does t solve any trust or auto issues, does it?
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.
It's not really for security or trust, but rather a temporary credential to avoid having them create an account during that precious first impression. They'd probably have to add a traditional password and email later on, but they could get started using it without needing that burden right away. I'd even be okay expiring the certificates after a week, since you should have a permanent account by then.
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.
My understanding of smart cards is that they are nothing more but a portable storage device for a certificate. While that certainly helps with the PITA complaint, what problem does a smart card solve in regards to identity that exporting and importing certificates doesn't?
Certificates are public, they don't need protection. The private keys do. That said you always want to store a certificate close to its private key for practical reasons.
Smart cards are useful to transform your keys into a real object that is carried around and presented upon request. They offer the interesting property that they cannot be copied or used by illegitimate users, at least not without spending horrendous amounts of time and money. When your smart card is lost or stolen you can always revoke the credentials it contains on the server side and get new ones. Much harder to know when your browser key store was stolen from your computer.
So it's the transformation to a physical "thing you have" that is valuable? Would you say it is any better than a physical one-time code generator? Again, beyond the PITA argument; having used both I completely agree that the card was a lot easier.
Definitely that, and the fact they cannot be copied. OTP fobs offer the same convenience but are based on shared secrets that can be stolen from the server (happened to RSA). With PKI your private key is only on your smart card and nowhere else.
We tried to use Client Certs at LogNormal for API calls, but the problem is that if you enable Client Certs on an HTTP server, all requests will be asked for a cert, which, on a browser, pops up a scary "Select certificate" message. Since we used the same nginx boxes to front all requests, and routed them to appropriate servers on the back end, we couldn't proceed.
I don't understand why sites need to control this. This is a browser problem, just like remembering the password, listing them and removing them is a browser problem. Why would the website have anything to do with managing client certificates, other than bypassing browser vendors for more flexibility (and thus more problems) ?
Yes, of course, there are some parts that must be dealt with by the site, but the article states a list of things that are outside the reach of what a website should have access to:
> 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
With regards to exporting and importing: The idea is definitely not any more dangerous than the already existant functionality for `<input type="file">`.
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?
> 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.
I use client side TLS certificates for several things, but usually not in a browser.
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.
I was authenticated this way with the StartSSL website if I remember correctly. While it sounds a good idea in theory, the UI part is indeed really really terrible and I had some trouble to find the right place myself so I can't imagine for a non-technical user.
I would like to use client certificate with distributed sensors, but I can't find a cloud provider that would accept them directly (and I would like to avoid using VMs and Linux myself, and let storage providers do it)
Did you consider using a decentralized solution like https://cloudfleet.io (I am a founder). If you are interested in a PoC, send me a mail, address in my profile.
we use this very extensively for authentication by partners. If our partners want access to our internal technical documents etc. this is the only way to get them by identifying yourself via client certs. The bigger issue is how do we go browser neutral when generating the CSR. On IE we have to resort to ActiveX since the HTML-keygen is not implemented in IE while Firefox does, so we have to code for the two different browsers we support.
I wouldn't list startssl certificates over letsencrypt as they aren't really free. I wonder how many of their free users actually paid the $25 to revoke their certificates after hearbleed.
Cookies (over SSL) can work if you only have one site, to store a session id or such. Since cookies could be replayed, they can't be used with multiple sites (that would be analogous to using the same password on multiple sites). Also, cookies are generally stored unencrypted on your hard drive.
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.
You're not incorrect, but that's not really the whole story either. If the thing the cookie is remembering is an authentication token, then the difference is more technologies involved than anything else. They are both "something you have", and they both provide proof of authentication to a site.
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.