
Why is nobody using SSL client certificates? (2008) - g1n016399
https://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
======
hannob
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.

~~~
true_religion
If you do EV, a client side cert will reveal a lot--essentially shouting your
real name and address to every router between you and the server.

However, what about self-signed certs?

~~~
cpach
Is EV really available for client certs?

------
babebridou
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.

~~~
INTPenis
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.

------
odc
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.

~~~
realusername
I indeed don't understand why it's not done yet, everything would be so much
easier !

~~~
dozzie
Oh, yes, let's add more attack surface to what we already have. Because
JavaScript interfaces are known for being well-thought and highly secure.

------
cesarb
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.

~~~
ordinary
I thought ephemeral keys prevent replay attacks as well. Is that incorrect?

~~~
dozzie
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.

------
reidrac
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.

------
netheril96
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.

------
7952
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?

~~~
jdmichal
> 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?

------
samuel
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.

------
PebblesHD
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.

------
cpach
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.

~~~
nicolas314
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](https://www.youtube.com/watch?v=ybNWOhI-Q-4)

------
MichaelBurge
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.

~~~
TheCondor
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.

~~~
MichaelBurge
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.

------
Spooky23
A: It's a pain in the rear.

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.

~~~
jdmichal
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?

~~~
nicolas314
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.

~~~
jdmichal
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.

~~~
nicolas314
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.

------
bluesmoon
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.

------
rakoo
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) ?

~~~
true_religion
Because you're using the certificate for authentication; its important that
you have a way of revoking old certificates and registering new ones.

This is pretty much analogous to what a website has to do when it uses a
username/password for authentication.

~~~
rakoo
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

~~~
jdmichal
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_?

~~~
rakoo
> 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.

------
janvidar
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.

------
realusername
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.

------
nraynaud
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)

~~~
DoubleMalt
Did you consider using a decentralized solution like
[https://cloudfleet.io](https://cloudfleet.io) (I am a founder). If you are
interested in a PoC, send me a mail, address in my profile.

~~~
nraynaud
I'll give it a look in February, if I get the job :)

~~~
DoubleMalt
Great!

~~~
nraynaud
I'm sorry, I had a look and I don't feel like your product will fit with a 3G
box that goes on top of a 120m windmill :)

------
pbhowmic
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.

------
sunng
We use client certificates for our internal services.

Also you should know that Apple use this for its push notification system.

But I still think the technology is underrated.

------
s_dev
Free SSL certs:

[https://www.startssl.com/](https://www.startssl.com/)

[https://letsencrypt.org/](https://letsencrypt.org/)

~~~
consto
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.

[https://www.startssl.com/Support?v=43](https://www.startssl.com/Support?v=43)

------
IshKebab
What does this solve that cookies don't?

~~~
nailer
Cookies are for remembering things, client-side SSL certs are for
authenticating clients.

~~~
jdmichal
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.

~~~
nailer
Yep but the data in the cookie was provided by the server, which had to
already auth you via some means. Like a password, or a client side SSL cert.

