
Why is nobody using SSL client certificates? - cottonseed
http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
======
pilif
I'm the author of this post which I have written in 2008. Since then my views
have changed a bit: for one, the added security is debatable as the client
cert is easily accessible to malware and thus could easily be stolen.

The other thing is that renegotiation is somewhat broken since that related
security flaw in 2010ish, so you can't have parts of a site accessible without
client certs and other parts requiring a cert.

This has been fixed since, but I don't know how well it's supported by
clients.

Finally, compared to 2008, we're using many more devices for accessing various
web applications now. Having the client cert bound to one browser on one
machine is annoying and synchronizing it truly securely is probably
impossible.

I do stand by the horrendous UI though. Even if the other issues weren't
there, the UI certainly kills client certificates for normal users.

Then again, crypto UI is hard and I'm afraid the incentive for redesigning
this is pretty much zero because nobody is using it to begin with and because
it's flawed anyways.

~~~
gcb0
the malware point is moot.

malware can steals passwords saved, which are optionally saved encrypted. the
cert at least in the one browser i checked is always encrypted.

and even then, if you have malware in your box, any and all security measures
are worthless at this point.

decent Renegotiation and mobile client support will come if people using that
on the desktop request the feature. it's like that for everything for a while
now.

Managing the devices and revokation is also trivial. most sites does that very
easily with API keys and cookies (e.g. google 2step auth, you can control
which cookies are still valids for the 'remember this device' feature). the
same logic could be used for client certs.

~~~
pilif
What I meant about malware is that client certificates can't provide
additional security over passwords because malware can easily steal both.

So it's only hassle and no advantage, hence, useless

~~~
drchaos
Other than passwords, client certs cannot be guessed or generated with
wordlists, they can not be used to authenticate to other sites even if stolen,
and they cannot be forgotten (at least I tend to forget passwords for rarely
used sites way more often than I lose data through HW failure).

So I'd say there are some advantages over passwords. And most of the
functionality is already there, the only thing missing is a browser function
to generate a keypair for a domain and send the public key, without much user
interaction.

~~~
deoxxa
That's already a thing, if I understand what you're asking - see the <keygen>
tag.

------
tptacek
Try having two client certificates and seeing the browser UX for selecting
which one to present to which site. You'll see why they aren't used.

Client certificates should be much more popular in backend applications, where
they're straightforward to use, flexible, and fairly trustworthy. But they're
not a good end-user technology.

~~~
jgrahamc
I agree that for machine to machine communication client certificates work
well. Especially if you implement your own CA so you don't worry about the
public infrastructure.

~~~
tptacek
If you're writing your own code for both sides, an approach that I've seen
work just as well is to keep whitelists of certificate fingerprints.

------
count
The whole DOD is using it, but they're on crypto smart cards, so many folks
don't realize that's what they're doing. Email, single sign on, web site auth,
etc. Works great!

~~~
Spearchucker
It's easy enough to use on a smart card, but try setting that up. I'm
trivialising now, but you're looking at...

\- Card manufacture

\- Key handling

\- Enrolment

\- Card lifecycle

\- Certificate lifecycle

\- Identity synchronisation

You could buy a stack of white-labelled cards, of it you're the DoD you'd roll
your own. That's shopping for silicon wafers, contact plate assemblies, mag
stripes, holograms, RFID blanks, plastic card blanks, and card stack.

Regardless of DoD or not, you've got to manage secure key transfer (keys
created at bureau, exported using GIS TX3 and multiple smartcards, sent to
client via multiple motorcycles, key reassembled and imported into HSM).

Enrolment is a hefty process. Apply for smart card. Personalise physical card
(typically photo and name), provision (link card to user), give card to user,
mail PIN to user (out of band), and then activate card.

That's just card manufacture and provisioning. Doesn't cover provisioning and
de-provisioning software and hardware, card lifecycle (suspend when lost,
disable if stolen or not found or employment terminated, and so on).

Then there's CA integration, (often multiple) directory integration, and
hardware integration.

The point of all this is that security _can_ be easy, but it comes with a big
fat price tag and some very specialised skill.

~~~
tlrobinson
Sounds like a business opportunity.

~~~
hpagey
There are several companies in this space. I was a research lead for smartcard
access project for iOS platforms. We had to perform two way handshake using
the certificates on the smart card. The most difficult part was to get data
signed by the private key on the card during the handshake process.

------
mgkimsal
Yes, it's true. Not sure why it's news, other than it's a new article?

This has been an abomination since .... the functionality was added. It's hard
even for geeks to deal with it - it makes _0_ sense for non-techies to even
contemplate dealing with it.

Relatedly, browser UI for dealing with cookies has been abysmal since day 1 as
well. Instead of making cookie information easily visisble and manageable,
browser makers resorted to shifting cookie mgt stuff around in 'preferences' a
few times (is it 'privacy'? or 'advanced'? why not 'cookies'?), and people
champion using specific browsers with specific plugins as an optimal solution.

Client certs are even worse off - few people even bother to write plugins to
deal with this stuff. It's chicken/egg as well - no point in updating browsers
to be better if no servers will modify their code to deal with it.

~~~
nathan_long
>> This has been an abomination since .... the functionality was added. It's
hard even for geeks to deal with it - it makes 0 sense for non-techies to even
contemplate dealing with it.

Are you criticizing the concept or the implementation?

Conceptually, for a user to maintain 1 or 2 "identities" on a machine seems
easier than maintaining 50 "logins", which already require a password manager
if you're using reasonably hard passwords.

~~~
mgkimsal
implementation. that's why it's not being used.

------
chrisfarms
I think this would need a total re-think before the masses could use.

I'd love to see browsers implement it by forcing people to store client certs
on a USB-key or a phone by default. I think some kind of physical item that
contains your keychain would be much more intuitive to many. Everyone is
familiar with mechanical keys, they know not to leave them around, they know
that they need them to unlock things and they know if they lose them they need
to replace them.

~~~
Cyranix
The analogy to mechanical keys doesn't hold up under closer scrutiny, though,
right? House keys don't serve as an identity, just an access mechanism. You
don't lose all future access to your house if you lose your keys; a locksmith
can independently verify (with reasonable certainty) that it's okay for you to
obtain a new set of keys which give access to the same house.

I feel like the human predisposition to risk aversion is even more of a factor
preventing adoption among average users than poor UX (not to mention lack of
awareness). What do I tell my parents when they ask "What if my computer
crashes? Would I not be able to log in to the website and see my stuff? What
good is using a website if I can't access it from any computer?"

Until something as securely portable and loss-resistant as one's own memory is
achieved, I don't see passwords being less popular than any other access
mechanism for the average user, no matter how significant the other downsides.

------
lmm
The key management tools are awful. People complain about the complexity of
PGP but at least there it's one-click to export a key, look at the details of
it, sign someone else's key etc.

But yeah, it would be nice to use this tech rather than reinventing the wheel.
The underlying implementation is sound.

~~~
area51org
The whole system, now close to 20 years old, needs a reboot. I know, that's
easy for me to say. But it's showing its age, and could really benefit from a
complete rethink.

~~~
lmm
Do you have specific criticisms? In cryptography, a system that has withstood
scrutiny for that long is a rare and exceedingly valuable thing. By all means
use it as the ugly foundations that you hide beneath the beautiful edifice on
top, but throwing it away would be madness.

~~~
area51org
You're right, I'm being vague. I'm looking for two things, really:

1- simpler implementation — one that is easier for users to understand, and
includes client certs by default

2- one with a re-engineered cryptographic implementation, one less likely to
have the kind of numerous security flaws that have been uncovered in SSL/TLS
over the years

SSL was originally meant to serve two purposes:

1- encrypt communication

2- _verify_ , through a trusted 3rd party, that the remote service you're
contacting is actually who it says it is

Most laymen, and many technologists, do not know that #2 even exists. Worse,
this authentication portion has been all but destroyed by liberal certificate
authorities like GoDaddy. From my experience, anyone can get a certificate for
a domain without any kind of check to see if you have the right to use that
domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a
cert for it, and start using it, without any kind of background check. In the
early days (when Verisign was the only CA in town), a business had to supply a
Dunn & Bradstreet number and be subject to other background checking before
being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't:
Verisign was supposed to have the users' backs. If you tried to get a cert for
Amaz0n.com, it would have been rejected unless you could prove you actually
are Amazon.com.

I think that kind of authentication has a real place on the modern Internet.

edit: formatting

~~~
lmm
>1- simpler implementation — one that is easier for users to understand, and
includes client certs by default

I'm not sure what you're suggesting. A nicer UI would definitely be a good
idea, but you can do that without changing the underlying crypto
implementation.

>2- one with a re-engineered cryptographic implementation, one less likely to
have the kind of numerous security flaws that have been uncovered in SSL/TLS
over the years

That's not how you get secure cryptography. You need not just a secure
algorithm but a secure implementation, one resistant to timing attacks,
compression attacks, and all sorts of nonobvious things. OpenSSL is far from
developer-friendly, but the vulnerabilities have been hammered out over those
20 years, and there is a body of knowledge on how to use it securely. A new
implementation would have to go through that all over again.

>From my experience, anyone can get a certificate for a domain without any
kind of check to see if you have the right to use that domain. So, in theory,
you could register "amaz0n.com" with GoDaddy, get a cert for it, and start
using it, without any kind of background check. In the early days (when
Verisign was the only CA in town), a business had to supply a Dunn &
Bradstreet number and be subject to other background checking before being
issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign
was supposed to have the users' backs. If you tried to get a cert for
Amaz0n.com, it would have been rejected unless you could prove you actually
are Amazon.com.

True enough, but fixing that doesn't require any changes to SSL itself - you
just have to curate the list of root certificates the browser trusts more
carefully.

------
616c
I use it for StartSSL. It allows me to use SSL client cert auth for their
OpenID instance.[0] I use it to log into StackOverflow and a few prominent
sites. I like the idea of my cert provider being a trusted party for auth for
other sites. However, trusting anyone other than himself in this post-PRISM
era is probably a mistake.

[0] [http://www.startssl.com/?app=14](http://www.startssl.com/?app=14)

~~~
icebraining
It's so annoying that OpenID providers either support client certs or using
your own domain, but never both!

~~~
616c
I have not tried both, so I did not experience this problem. I do know SSL
client certs do not work well, and wanted to work on building my own solution
that does what StartSSL (an OpenID endpoint with SSL-cert based
authentication). Does anyone know of ways to do this?

~~~
icebraining
Nginx supports client certs[1], so I'd say the easiest way to get started is
to get some free OpenID server (SimpleID[2] seems maintaned) and configure
nginx to require cert authentication to access the login path.

I'd do it myself, if I used OpenID more than once every two months or so.

[1]: [http://nategood.com/client-side-certificate-
authentication-i...](http://nategood.com/client-side-certificate-
authentication-in-ngi)

[2]: [http://simpleid.koinic.net/](http://simpleid.koinic.net/)

------
rmoriz
Same goes for S/MIME which uses X.509, too. But S/MIME recently got traction
and usability again because of OSX Mail.app and iOS mail support.

People should really consider S/MIME for mail encryption as nearly every MUA
(mail client) can deal with it and large institutions already use it (e.g. for
SSO)

[https://gist.github.com/rmoriz/5945400](https://gist.github.com/rmoriz/5945400)

------
lwf
MIT uses it, [https://ca.mit.edu/](https://ca.mit.edu/), but its a constant
source of helpdesk headaches. Managing renewals and revocation is hard.

------
nstielau
We are using client-side SSL certificates extensively for API as well as
browser-based single-sign-on for 20+ employees on a smattering of
Mac/Linux/iPhone/Android devices. Definitely some ramp-up and wonkiness, but
it's working well.

Also worth noting that infrastructure components like Cassandra [1] and
RabbitMQ [2] leverage PKI as well.

Checkout our Jenkins client-side SSL cert auth plugin:
[https://github.com/pantheon-systems/certificate-
authenticati...](https://github.com/pantheon-systems/certificate-
authentication-for-jenkins)

[1]
[http://www.datastax.com/documentation/cassandra/1.2/index.ht...](http://www.datastax.com/documentation/cassandra/1.2/index.html#cassandra/security/secureSSLCertificates_t.html)
[2] [http://www.rabbitmq.com/ssl.html](http://www.rabbitmq.com/ssl.html)

------
superuser2
It's worth noting that MIT uses these. New students are provisioned client
certs, which are accepted for login to institutional websites and even Apple's
MIT student discount page. Not sure if any other universities are using this.

~~~
vabmit
Yes. But, it's worth adding that MIT also uses a Shibboleth implementation
(locally called Touchstone). On many core sites Touchstone handles
authentication to the specific web servers. Touchstone itself can be
authenticated to with either the individual X509 client cert or their
password. Many people use password authentication to with the Touchstone
server even though MIT has a website that (usually successfully)auto generates
and installs the certificate in the user's browser.

~~~
krilnon
Any idea how many people primarily use passwords? Personally, I've always
found it really convenient to use certs for MIT and CSAIL stuff.

------
wmil
That's just installing it on a desktop. Try installing an SSL certificate on a
mobile browser.

~~~
aroch
Both iOS and Android allow you to easily provision keys to a device...

~~~
m_ram
Thanks for that. In case anyone else is interested:
[https://support.google.com/nexus/4/answer/2844832?hl=en](https://support.google.com/nexus/4/answer/2844832?hl=en)

------
andyhmltn
Correct me if I'm wrong, but unless they can be password protected (which
defeats the object...) aren't they less secure than passwords in practice?

I have a password on my phone, because I don't want people with access to it
to be able to login and look at my stuff. What's to stop my friend Joe Blogs
coming over my house and being able to read my email because I have one of
these things installed that allows for a one-click login?

~~~
icebraining
_Correct me if I 'm wrong, but unless they can be password protected (which
defeats the object...) aren't they less secure than passwords in practice?_

The most important difference is that attackers can't get it from the server
and re-use it on others, since the server only needs to see the public key of
the cert. Attackers can no longer break into a single server and get thousands
of badly-secured passwords.

Of course, secure password hashing mitigates this issue, but that means we
need to trust each and every server out there to implement that correctly (not
likely), while this only requires a correct implementation from the browsers.

------
wmf
I see Persona as the next generation of client certs with usable UX. People
are working on this problem, just not within SSL/TLS this time.

~~~
h8trswana8
Sure, if you like your password going through Mozilla's server unencrypted.

~~~
wmf
Then don't use Mozilla's server.

(There's a tough choice here: Persona's crutches make it much easier to deploy
incrementally, but there's no incentive to ever get off the crutches and
people think that the crutches _are_ Persona.)

------
enricopulatzo
My suggestion for fixing the client cert problem is to task the browser with
certificate generation upon profile creation. There are significant security
implications of course, but sites aren't really incentivized to support client
certificates.

If 50% of my traffic already tried offering me a client cert the decision to
allow them would be an easy one to make.

------
joshuaellinger
The reason I would like a client certificate solution that worked (even if it
was a malware target) is that I could reject all web traffic to my
applications if they came in without a cert. It would decrease my public
footprint dramatically.

I don't mind approving a user once per device. We've got to set them up
anyway.

~~~
marshray
Use client certs then? Why do you feel current solutions don't work?

~~~
joshuaellinger
Setup is still too painful even with direct support.

------
7952
I find it hard to believe that client certs offer much advantage over cookies
for most normal web sites.

Even if it was common practice you would still need some way to recover an
account after loosing a certificate, at which point an email will be sent out
with a password equivalent reset token, so why not just use a password?

Storing certs client side just creates another target for malware, even if the
certificate is password protected. You could move the certificate to a key
fob, but at that point why not just use a separate second factor token? You
would either have a full sense of security, or have to trust that the client
machine is fully secure (impossible).

It is much more sense to focus on making cookies as secure as possible by
setting secure headers, and invalidating cookies that come from a machine that
is different than expected.

~~~
wmf
_an email will be sent out with a password equivalent reset token_

This is not the only way to do resets and is arguably now the weakest link in
authentication (just ask Matt Honan). Sometimes I imagine a world where
authentication enrollment and resets are done in person.

~~~
7952
Agreed. Although sending an SMS goes a long way to solving this.

------
captainmuon
CERN (and other research facilities) use these a lot, to manage access to
their internal websites and to the grid (the distributed computing platform).
IIRC, you have a cern account, and generate a short-term certificate with
which you work. You can use it to submit jobs into the grid, but you can also
import it into the browser to access e.g. grid monitoring software, or
internal wikis. The idea is that in the worst case that you lose the
certificate to a hacker, it can be revoked quickly without having to block
your whole account.

The last time I checked (haven't worked with CERN's computers or the grid for
a while), it was pretty user-unfriendly. Obscure shell scripts for everything.
It hopefully improved since then. OTOH, it's probably good enough for
programmers and researchers.

------
ninjakeyboard
Buddy, why is nobody using SSL certs anywhere AT ALL?? Plain text passwords
are sent on the login forms from sites like Hackathon.io - sites used where
hundreds of people meet in a room on the same damn wifi network. RIDICULOUS!!
what the hell!

------
sweis
I've seen client-side certificates work in large organizations (e.g. MIT).
However, this was in the pre-smartphone era. They just had to support IE,
Safari, and Firefox. That was still a pain.

Today, it's much harder to support every browser and OS.

------
joshuaellinger
Yep -- too hard to setup.

A really good browser enhancement would be 1-click client side certificate
setup.

~~~
evilpie
Pretty sure that you could write an Firefox addon for this.

------
dclowd9901
This is the kind of tech Bump needs to get on -- auth and identity management.
They showed a way a while back to upload an image by "bumping" your phone on
your keyboard. Since phones are singular and ubiquitous and have their own
identifiers, your phone could essentially become a makeshift physical key. You
could log into any machine, public or private, with a simple "bump" of the
keyboard. So Bump, if you're listening, create a Bump Auth.

Of course if you lost your phone or someone stole it, that would be
problematic, but I don't anticipate you'd use this as a way to log into your
bank account.

------
conexions
I always wished we could use SSL the way we use phisycal keys. They are a very
good example encapsulization and easy user interface. When you use the key for
your house, you look for a certian color or shape of the key. Most users don't
know or care how the lock works. Why can't SSL be this way. Instead of having
the end user chose a password have the browser automaticaly generate a
public/private pair. For the user interface make a key with a random or user
generated design. When the user goes to the website again present the user
with a list of their keys and have them chose the correct one.

~~~
keeperofdakeys
The first part, moving authentication from the user to the browser, is exactly
what Mozilla's Persona is about. However, the whole "multiple device" thing
kind of kills browser-level authentication (persona gets around this by
allowing email accounts).

------
jpalomaki
Using the TPM to store the client certificates would prevent malware from
stealing them. I have no experience on this, but quick search revealed
something[1].

Maybe one use for securely stored client side certs would to mark the computer
as trusted. For example now Google is probably using cookies to determine that
my desktop is trusted and thus I don't need the two-factor authentication to
log in. TPM and client side certs could provide more secure alternative for
this.

[1] [http://blog.habets.pp.se/2012/02/TPM-backed-
SSL](http://blog.habets.pp.se/2012/02/TPM-backed-SSL)

------
NDizzle
I used SSL client certificates with a Lotus system from 2000 to ~2011. They're
still in use today, I just no longer work there.

It's pretty easy maintenance once you set up systems for account managers to
generate and issue new certificates for people.

Then again, this was small time. Few thousand active users. Niche bio/pharma
web application.

Large scale it could very well be a bitch and/or unnecessary at this point in
time.

The system was designed/created between '96 and '98 and has used certificates
the entire time.

------
arnehormann
In theory, it's a little simpler - at least for new keys... See
[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/ke...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/keygen) and
[http://www.w3.org/TR/html5/forms.html#the-keygen-
element](http://www.w3.org/TR/html5/forms.html#the-keygen-element)

------
davidu
We use client-side PKI and certs, not just with employees, but with customers,
at OpenDNS.

Works well, is a very strong added factor, and is easy to manage and deploy
these days.

~~~
clarkevans
What tool(s) do you use to manage your CA? Overall, this is one of the bigger
challenges... I don't know of any open source project (or even SaaS) that
implements a full CA workflow including signup, approval, revocation, etc.

------
enricopulatzo
While the UX side of things could be made quite simpler, but I think a
significant hurdle for client certificates is authentication through proxies.

------
hpagey
Client certificates won't work well if you are trying to authenticated against
services inside the corporate network (sharepoint, microsoft exchange, AD) and
your connection passes through proxies such as Microsoft TMG. Your SSL
connection will be terminated at such a proxy and you will have to setup
kerberos or impersonation. It is doable just tricky to setup.

------
bonaldi
We use these at work, and once set up they're a breeze. But that's a big
"once".

It also makes life needlessly difficult if you want to log in to something
from a new/borrowed/etc PC and don't have the keys handy. Where needlessly =
near-impossible.

------
coda_
I haven't been able to get a client certificate working on Android at all
(stock 4.2.2 with Chrome and Chrome Beta). Perhaps someone here has gotten
them to work? I've posted in several forums and haven't found anyone that's
gotten them to work.

~~~
nicolas314
It definitely works with recent Chrome versions. I use this daily to check my
professional webmail on an Android 4.2.2. Once you have provisioned a PKCS#12
into your keystore, open Chrome onto an HTTPS web site that requires
certificates from your issuer and the certificate choice dialog pops up.

------
revaaron
They're used extensively in a lot of industry- just because it isn't used for
logging onto Gmail doesn't mean it isn't used elsewhere. I work in utilities
and client certificates are used for all or nearly all web clients and APIs.

------
mike-cardwell
I think the main problem is the effort of having to maintain a client
certificate. I.e, backing it up and copying it on to other devices. It's so
much easier to just remember a password, or write it down if you can't do
that.

------
christefano
I'm surprised no one has mentioned WebID yet:

> [http://webid.info/](http://webid.info/)

WebID works (I saw it demoed at a meetup earlier this year), though I'm not
sure how popular — or unpopular — it is.

------
rpug
The guys at CryoKey ([https://www.cryokey.com/](https://www.cryokey.com/)) are
basically trying to do this. I haven't personally used it, though.

------
contingencies
Had to deal with this once or twice for some integrations. It's a PITA for
little additional security. Often you can just use a VPN or IP restriction
instead.

------
njharman
> basic authentication (nobody uses this one)

Huh? I use that all the time.

------
lessnonymous
Anyone know of a good tutorial for using client certificates for (2nd factor)
authentication? A quick Google search brings up nothing useful.

------
throw7
I would think getting your cert signed by a CA is a significant barrier to
entry also.

------
D9u
I love the graphics... The user responses to the settings screens are
hilarious!

------
dedward
Short answer: it's a pain in the butt.

------
tomgirl1
Im at a loss, but my first instinct is to say that server certs arent
validated properly AT ALL, so I fail to see how client certs would do any
better.

For all the hype over PFS (perfect forward secrecy) I dont see how how MITM
attacks are stopped because cert validation is so bad or nonexistent I dont
see applying more certs (plus diffie hellman) to be a solution.

~~~
mtrimpe
They're as secure as your ability to keep the private keys private, just like
with server certs.

As far as MITM and PFS goes; that's handled just the same as regular SSL.
Using a client cert doesn't affect that at all.

~~~
tomgirl1
Which is not secure at all. you can MITM a typical SSL connection in so many
ways SSL might as well not exist.

No real cert validation, forged certs, proxy replays. SSL is a joke.

~~~
xnyhps
Most places where you can authenticate with SSL client certs allow you to add
your own self-signed certificate and authenticate using that. All the
validation you need is to check wether the cert is in the user's list. You can
only forge that by stealing the private key.

There's really no reason to only allow CA signed client certs.

------
AsymetricCom
No or insignificant economic incentives.

