5 ms·

Client-side TLS certs have been a thing approximately forever, yet everyone is hesitant to use them because... installing a cert in your browser is hard, I gues

Client-side TLS certs have been a thing approximately forever, yet everyone is hesitant to use them because... installing a cert in your browser is hard, I guess? Many corporations and agencies use certificates either as the primary (only) auth method, or as supplementary auth. For example, DTrade, the US defense export licensing system: http://www.pmddtc.state.gov/DTRADE/index.html http://www.pmddtc.state.gov/DTRADE/index.html We use them at work and they work great. Pretty much instant auth to any internal site with no shenanigans.

arnarbi 9y ago
Since it's at the TLS level, the frontend/load balancer would have to deal with user authentication, which can be challenging.
lawl 9y ago
They are also not trivial for webdevs to implement, since the webapp usually doesn't terminate the TLS connection itself.
- gruez 9y ago
  Is that really an issue? AFAIK on nginx you can have it forward the certificate in a header.
  - andrewaylett 9y ago
    It's an issue if you use a CDN or other platform-provided TLS terminator; they don't usually support client certificates. And even if you _can_ support it in your reverse proxy and put the certificate details in a header, that's a very different server-side interface from terminating the client TLS connection in the service itself.
- parliament32 9y ago
  Wouldn't that make it easier? In an nginx use case, nginx handles verification and termination, and just passes a user identifier variable back to the origin.
- GordonS 9y ago
  The web server usually handles that side of things. The big problems you have are private key generation, certificate distribution, revocation, renewal, and guiding your users on how to install the damn things.
  - orf 9y ago
    So now your authentication logic lives in your Nginx config. That's not great, and it's not where it should be.
  - orf 9y ago
    So now your authentication logic lives in your Nginx config, a rather odd language with it's own fair share of quirks. That's not great and it's not where the logic conceptually fits.
    - slrz 9y ago
      You generally setup the reverse proxy to pass the required information to the backend via some trusted mechanism (e.g. HTTP headers not settable through client requests).
GordonS 9y ago
I used them for an extranet system I built around 10 years ago. Certificates are a total PITA, and users hate them - they need to be provided with step by step instructions on how to install them, and they still manage to struggle with it. Plus the procedure differs between browsers. And they generally have private key export disabled, so you can only use them on the machine you first installed it to. Oh, and some companies have things so locked down that users can't install client certs at all! Things have barely changed here, so I avoid certs for users - having said all that, they work great for authentication between software components where there are no pesky users involved.
- parliament32 9y ago
  There is a way to "offer" a client cert bundle to a browser, where the browser would simply ask the user whether they want to accept the personal cert into their trust store. Pretty smooth process. As for downsides, yes, no exporting: users have to go through the enrollment process with each new device.
  - GordonS 9y ago
    > Pretty smooth process You wouldn't say that if you'd had to support our users! At least when we created the system, the method of private key generation differed from browser to browser. Then we had to sign their CSR in our offline PKI system and email them a password-protected PKCS#12 certificate bundle, and send them the password out-of-band. Finally, they had to import the bundle into their browser. It could have been simpler, but "big corporation" :(
    - tialaramex 9y ago
      Either this description is wrong, or this process is crazy, or both. The whole _point_ of a CSR is that you don't need any secrets. The CSR proves that its creator has some private key in their possession and wants a certificate. You need to verify that whoever presented the CSR is really who they said they are (this is hard, hence ACME for the Web PKI, but it's out of scope for the Public Key Crypto problem) and then you issue a Certificate, which isn't secret. Emailing PKCS#12 bundles (which have a key inside them) is asking for trouble but more importantly here: if the user already has a perfectly nice key, why are you sending them a new one ?
e12e 9y ago
Unfortunately client certs (broken as the ux was) is headed out of browsers :/
atonse 9y ago
And then how do you logout? How do you handle people wanting to login to a shared computer? (like in a conference room)
- parliament32 9y ago
  No logging out. You're no longer authenticating "users", you're authenticating "devices". This is in a corporate setting, of course, where if there's a shared computer each user logs in to their own environment via LDAP/AD/whatever.
jiveturkey 9y ago
Yes, it is hard, and the UX is horrible. Google proposed, and Chrome implements, Origin-Bound Certificates (http://www.czeskis.com/research/pubs/tls-obc.pdf http://www.czeskis.com/research/pubs/tls-obc.pdf) which are just about as good and with no UX impact. Section 8 covers many of the problems with TLS client certs. AFAIK Chrome has the only implementation of OBC.
mr_toad 9y ago
Do any mobile browsers even support them?
tialaramex 9y ago
Client certs have a problem Web Authn doesn't have which is they enable tracking, very trivially. With client certs, I sign into Facebook, Hacker News, LWN, and all three of them get told "This is tialaramex, serial number 183749265". So does LegitAds, and XHamster, and Penny Arcade. Which is great for advertisers, but probably not what most users want. With this technology, each site gets a consistent but site-specific identity. So they know it's still "me", but they have to collaborate out of band to discern that all these people are the same person, as they would without any authentication framework. The requirement for user action to authenticate has a benefit here too - advertisers even if they have Facebook's permission to check which Facebook user I am, daren't risk saying "Er, hi, can you just sign into Facebook for us?" because it's obvious what's going on. Only the places which already explicitly need authentication will ask.
baud147258 9y ago
The system we're building (and selling to big US administration groups) uses certificates to authenticate. I've never found installing a certificate hard.

arnarbi 9y ago

Since it's at the TLS level, the frontend/load balancer would have to deal with user authentication, which can be challenging.

lawl 9y ago

They are also not trivial for webdevs to implement, since the webapp usually doesn't terminate the TLS connection itself.

gruez 9y ago
Is that really an issue? AFAIK on nginx you can have it forward the certificate in a header.
- andrewaylett 9y ago
  It's an issue if you use a CDN or other platform-provided TLS terminator; they don't usually support client certificates. And even if you _can_ support it in your reverse proxy and put the certificate details in a header, that's a very different server-side interface from terminating the client TLS connection in the service itself.
parliament32 9y ago
Wouldn't that make it easier? In an nginx use case, nginx handles verification and termination, and just passes a user identifier variable back to the origin.
GordonS 9y ago
The web server usually handles that side of things. The big problems you have are private key generation, certificate distribution, revocation, renewal, and guiding your users on how to install the damn things.
- orf 9y ago
  So now your authentication logic lives in your Nginx config. That's not great, and it's not where it should be.
- orf 9y ago
  So now your authentication logic lives in your Nginx config, a rather odd language with it's own fair share of quirks. That's not great and it's not where the logic conceptually fits.
  - slrz 9y ago
    You generally setup the reverse proxy to pass the required information to the backend via some trusted mechanism (e.g. HTTP headers not settable through client requests).

GordonS 9y ago

I used them for an extranet system I built around 10 years ago. Certificates are a total PITA, and users hate them - they need to be provided with step by step instructions on how to install them, and they still manage to struggle with it. Plus the procedure differs between browsers. And they generally have private key export disabled, so you can only use them on the machine you first installed it to. Oh, and some companies have things so locked down that users can't install client certs at all! Things have barely changed here, so I avoid certs for users - having said all that, they work great for authentication between software components where there are no pesky users involved.

parliament32 9y ago
There is a way to "offer" a client cert bundle to a browser, where the browser would simply ask the user whether they want to accept the personal cert into their trust store. Pretty smooth process. As for downsides, yes, no exporting: users have to go through the enrollment process with each new device.
- GordonS 9y ago
  > Pretty smooth process You wouldn't say that if you'd had to support our users! At least when we created the system, the method of private key generation differed from browser to browser. Then we had to sign their CSR in our offline PKI system and email them a password-protected PKCS#12 certificate bundle, and send them the password out-of-band. Finally, they had to import the bundle into their browser. It could have been simpler, but "big corporation" :(
  - tialaramex 9y ago
    Either this description is wrong, or this process is crazy, or both. The whole _point_ of a CSR is that you don't need any secrets. The CSR proves that its creator has some private key in their possession and wants a certificate. You need to verify that whoever presented the CSR is really who they said they are (this is hard, hence ACME for the Web PKI, but it's out of scope for the Public Key Crypto problem) and then you issue a Certificate, which isn't secret. Emailing PKCS#12 bundles (which have a key inside them) is asking for trouble but more importantly here: if the user already has a perfectly nice key, why are you sending them a new one ?

e12e 9y ago

Unfortunately client certs (broken as the ux was) is headed out of browsers :/

atonse 9y ago

And then how do you logout? How do you handle people wanting to login to a shared computer? (like in a conference room)

parliament32 9y ago
No logging out. You're no longer authenticating "users", you're authenticating "devices". This is in a corporate setting, of course, where if there's a shared computer each user logs in to their own environment via LDAP/AD/whatever.

jiveturkey 9y ago

Yes, it is hard, and the UX is horrible. Google proposed, and Chrome implements, Origin-Bound Certificates (http://www.czeskis.com/research/pubs/tls-obc.pdf http://www.czeskis.com/research/pubs/tls-obc.pdf) which are just about as good and with no UX impact. Section 8 covers many of the problems with TLS client certs. AFAIK Chrome has the only implementation of OBC.

mr_toad 9y ago

Do any mobile browsers even support them?

tialaramex 9y ago

Client certs have a problem Web Authn doesn't have which is they enable tracking, very trivially. With client certs, I sign into Facebook, Hacker News, LWN, and all three of them get told "This is tialaramex, serial number 183749265". So does LegitAds, and XHamster, and Penny Arcade. Which is great for advertisers, but probably not what most users want. With this technology, each site gets a consistent but site-specific identity. So they know it's still "me", but they have to collaborate out of band to discern that all these people are the same person, as they would without any authentication framework. The requirement for user action to authenticate has a benefit here too - advertisers even if they have Facebook's permission to check which Facebook user I am, daren't risk saying "Er, hi, can you just sign into Facebook for us?" because it's obvious what's going on. Only the places which already explicitly need authentication will ask.

baud147258 9y ago

The system we're building (and selling to big US administration groups) uses certificates to authenticate. I've never found installing a certificate hard.