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.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
