[cryptography] Client TLS Certificates - why not?

ianG iang at iang.org
Tue Mar 5 07:08:34 EST 2013


On 5/03/13 03:26 AM, Joe St Sauver wrote:
> Hi,
>
> strife asked:
>
> #Can anyone enlighten me why client TLS certificates are used so rarely? It
> #used to be a hassle in the past, but now at least the major browsers offer
> #quite decent client cert support,
>
> Not quite seeing eye-to-eye with you on the "quite decent client cert
> support" point, I'm afraid. Client cert user interaction still deserves
> poor marks for complexity and user opacity, I think.


Yes, I agree that browsers don't really support client certs.  Reasons 
are the same old same old.

> I did a preconference seminar for Educause Security Professionals 2012 on
> client certificates, and it's actually sort of surprising how deeply buried
> many bits of the current browser client cert implementation are. See
> http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf

Nice work!
...
> Assume the average person has multiple devices these days -- maybe a
> desktop at work, a laptop for travel, a tablet at home, a smartphone, etc.
>
> If I want to use client certs for encryption/decryption, I need the *same*
> cert on all of those devices,


No you don't - you need the same *claim* on all those devices if you are 
going to treat them all within the same claim domain.

If you have a system that promotes certs, then this is easy enough. 
Unfortunately we don't have that, as for various reasons, certs are seen 
as something one has to attach a high value to by suppliers.  So they 
get what works for that business proposition - nothing.  Which is to 
say, certs can do that job.  It isn't the certs that are at fault; if 
the CAs insist that they can sell an unsellable client cert to people 
for every one of their devices, it's no surprise this market continues 
to say "no thanks, we'll stick to passwords."

This whole argument that certs aren't portable across devices is 
something of a strawman.  Companies deploy SSL certs across accelerators 
all the time, so why not client certs?  The reason is the assumptions 
that are designed to stop you doing that.  Get rid of those assumptions, 
and client certs work.


> or on a portable device (such as a USB-format
> PKI hard token, or a smart card) so I can take my credentials with me.
> Sync'ing certs from one device to another isn't totally impossible, but
> backing up, manually transfering and reinstalling certs on multiple devices
> really isn't simple enough for most mere mortals. [Attempts to deploy a
> unique client cert to each device have issues of their own that we'll
> skip for the purposes of this note]


:)

> Smart cards or USB-format PKI hard tokens are a nice alternative, but
> somewhat expensive, and you can't just run down to your favorite local
> office supply store or neighborhood compute supply store and buy one.


Smart cards and USB-format PKI are a dead loss.  They are unworkable as 
a tech, 20 years of experiments have shown this beyond a shadow of a 
doubt.  If there is any future in smart cards or any other form of 
fantasy token, it will come via its humbler cousin, the cert stored in 
the browser or the software app.  Later on, once that has proved the 
model, it might be possible to pay the huge cost of smart card deployment.

Maybe.  But until then, any talk of hardware is in sci-fi fantasy la-la 
land.

(update:  having skimmed your talk, I see your success story, and it's 
only a small matter of inclusion, to whit:  USA federal government is a 
model citizen of sci-fi fantasy la-la land.)

...
> Bottom line, I think that there's still a lot of work ahead if you want
> to do client certs at scale...



Client Certs work, if they are targeted at website authentication as a 
password replacement.

Unfortunately there is a bit of a chicken and egg problem [0].  Software 
will only evolve if there is a serious amount of market - if lots of 
people demand this.  And nobody will demand this unless the software 
handles it well, which is not generally the case here.

This is actually pretty easy.  Here's the story:  a website runs its own 
CA.  For every enrolment of a customer, it issues a client cert to that 
customer (the browsers include code to trigger creation of that key & 
cert).  It enrolls that cert for that customer for this site only, and 
demands a cert every time someone touches the site.

Done deal.  It works.  Hey presto, passwords gone.  Now, the, security 
question that is going on here is the same one as always:  is this 
operation now *more secure than the alternative* being passwords?

Any larger website could do this - the code isn't that complicated, it's 
about a month or two.

The security *failure* here is to compare it to some 'best practice' 
shlock bible story from the industry that was written for other purposes 
than your security, and ask whether it is better than some mystical 
perfect fairy tale that isn't really relevant.



iang



[0] CAcert solved this chicken and egg by providence, rather than 
design, read here:

http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing

The point being that once solved, it worked.



More information about the cryptography mailing list