On 4/03/13 10:22 AM, [email protected] wrote:
Hi,
Can anyone enlighten me why client TLS certificates are used so rarely?
My thoughts only, not authoritative.
The big answer today is momentum, I would say.
In the past, I would say that forces were deployed against TLS
certificates. The CAs did not push them because the market for selling
client-side certificates at a commercially sensible price wasn't there,
it's a loss making proposition. Still isn't/is. But what they did do
successfully is convince people that certificates not signed by
browser-CAs were evil. They got their cake and their still eating it.
The combination of these forces pushed all the developers over to
passwords, and they've been on that since forever. Same cake, now about
18 years old, and causing predictable tummy aches.
It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".
Browsers need a couple of things: create a new cert on the fly, and to
fix the certs on a per-site level. But more than anything, they need to
get their heads out of committee holes and start doing real security
work for themselves. Thankfully that seems to be happening over at google.
With CAcert, there is even an excellent infrastructure in place that could
allow people to generate signed pseudonymous client certificates. A
service provider could limit the amount of certificates allowed per user
(as validated by CAcert), maybe even the amount of points required etc.
As you mentioned it: CAcert tried to move all its infra over to
certificates. The results were mixed. Some things worked very well,
somethings less well. However, the places where things worked less well
were pretty much all to do with the software just not evolving in that
direction.
My personal experience is that writing the cert-based user
authentication is easier and more robust than writing the password
authentication system. (I've done both in PHP.) But it does require a
bit more than copycat design :) For example, one has to find a way to
handle multiple certs for the same person, which requires one to stress
the claims of the CA more than they are capable of being stressed. In
particular, if cert A says "John Smith" and cert B says the same "John
Smith", are we happy? I was... but I had to windmill it a little.
That way, one could provide services without the requirement of
registration, and still effectively limit abuse?
Certs solve the spam problem, and the password security problem. And
the phishing problem. Oh, and the lost password problem, as a bonus :)
More or less, or, at least, certs lift the bar a long way.
What's more, if they were used more often, and client & server software
were to evolve to respect them, we'd be halfway to a decent security
model. For example, properly used (afair, impossible in current
browsers because we can't easily get general signing access to the certs
from say javascript) we'd be able to use the certs for proper
transaction signing, which would get us decent accounting software
instead of the "don't click Pay twice" nonsense standard aka online banking.
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
