Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is nobody using SSL client certificates?

pilif.github.io

Post reply on HN
Print view View original

61–70 of 160 posts

Re: Why is nobody using SSL client certificates?

#61

Post by sanderjd »

lmm wrote: post #12
area51org wrote: post #6

Earlier quoted context omitted.

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.

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.

I think the strongest criticism is that nobody on the mainstream internet is using this stuff. I'm not sure what your parent meant by a "complete reboot", but my interpretation is that all of the user experience needs a reboot, not the underlying crytpo.

Re: Why is nobody using SSL client certificates?

#62

Post by Spearchucker »

count wrote: post #11

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!

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.

Re: Why is nobody using SSL client certificates?

#63

Post by wmf »

h8trswana8 wrote: post #58
wmf wrote: post #55

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.

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

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

Re: Why is nobody using SSL client certificates?

#64

Post by steveklabnik »

h8trswana8 wrote: post #58
wmf wrote: post #55

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.

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

BrowserID requires nothing from Mozilla. They of course offer a public server so that you don't have to run your own server if you don't want to, but it's entirely, 100% optional.

Re: Why is nobody using SSL client certificates?

#65

Post by icebraining »

tomgirl1 wrote: post #28
mtrimpe wrote: post #26

Earlier quoted context omitted.

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.

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.

Proxy replays? How so?

As for cert validation / forged certs, they're only problematic because we want to authenticate a server we have never talked to before. With clients certs, the same doesn't apply: the server just needs to ensure the client is the same as the one who registered the account, so there's no need for the whole CA enchilada.

Re: Why is nobody using SSL client certificates?

#66

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

Re: Why is nobody using SSL client certificates?

#67

Post by danielsju6 »

wmil wrote: post #7

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

SCEP via .mobileconfig on iPhone, it's a breeze; I use client side certificates in a lot of places and the UX is transparent so long as the device doesn't contain multiple certificates.

Re: Why is nobody using SSL client certificates?

#68

Post by snuxoll »

jleehey wrote: post #40
lcampbell wrote: post #30

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.

> After the cert has been verified, you're free to pull the card out.

Last time I checked DoD systems are configured to automatically log you out of your session upon removal of your CAC.

Re: Why is nobody using SSL client certificates?

#69

Post by tlrobinson »

Spearchucker wrote: post #62
count wrote: post #11

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!

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

Sounds like a business opportunity.

Re: Why is nobody using SSL client certificates?

#70

Post by danielsju6 »

pilif wrote: post #46

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

The UX on iPhone isn't so bad if you are using .mobileconfig's and there aren't conflicting certificates. I'm actually starting to open source some of my work in this space.

OSX will still prompt for the certificate even if there is only one matching, but again it isn't too bad.

Though in iOS 7 / Mavericks I'll probably switch to using Keberos, which will be seamlessly integrated into the Objective-C's networking APIs.

Post reply on HN