Live data from Hacker News

Why is nobody using SSL client certificates?

pilif.github.io

51–60 of 160 posts

Re: Why is nobody using SSL client certificates?

#52
post #24

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…

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.

Re: Why is nobody using SSL client certificates?

#54
post #48

Earlier quoted context omitted.

doesn't particular matter if you know what they mean. A sidepanel that can open up at the click of an icon which tells me that 9 cookies were used, and they're set by google and yahoo and bing and 5 sites I've never heard of... that would give a lot of visibility immediately to people. Giving them an option of deleting/removing/blocking right from that sidepanel would empower people to be able to deal with it themsel…

When I click on the https padlock on this site, chromium shows me 1 ycombinator cookie and 0 third-pary cookies. In 2 clicks I can block the cookie, if I so choose.

When we all start using SSL for everything, perhaps that's a way to go.

If it's so simple, why don't we have a cookie icon up there so that it's visible all the time though?

EDIT: it's that way for non-ssl sites too - thank you - I learned something new - I may have to switch to chrome as my primary browser again. :/

It's still not quite as easy as I'd hoped for, because it's mixing cookie data and other stuff in the same popup panel, but it's a start. Having it be a cookie icon so it would be easier to know what you'll get when you click it (perhaps a separate icon) would still be better.

Re: Why is nobody using SSL client certificates?

#56
post #52
post #24

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…

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.

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

Re: Why is nobody using SSL client certificates?

#57
post #12

Earlier quoted context omitted.

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.

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-…

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

Re: Why is nobody using SSL client certificates?

#60
post #40

Earlier quoted context omitted.

My understanding is that the private key is on a CAC card[1,2], which is issued to all DoD employees and contractors who need access to DoD resources. Readers are usually built into the keyboard, and I'm guessing that there's something similar to ssh-agent running to maintain the key until you're AFK. -- [1] http://en.wikipedia.org/wiki/Common_Access_Card [2] http://www.cac.mil/

As a DoD CAC user and developer, this is correct (although the card readers at my company are built into the laptop or inserted via a USB adapter). I don't think there is a background agent that maintains the key though, I just think the card reader is queried when the certificate is needed. After the cert has been verified, you're free to pull the card out.

The key never leaves the smartcard: the card hardware will not allow it to be retrieved. Rather, your system has drivers which ask the card to do all of the signing operations which your system would normally do if it had access to a key.
Post reply on HN