3 ms·

I recently found out about TLS client authentication via client certificates. It seems like a really secure mechanism for authentication that just doesn't have

I recently found out about TLS client authentication via client certificates. It seems like a really secure mechanism for authentication that just doesn't have a standardized UX/API for initial cert exchanging and multiple device registration. I am hesitant to rely on a 3rd party SSO provider to remain available. I would much rather rely on a decentralized technology like the TLS certificate network.

LeonM 8y ago
I did use client side certificates for a while. It's a real pain to get the certificate installed, as it is different per OS and browser. And I wouldn't call it 'really secure', I'd say it's just as secure as any other client side secret.
- Boulth 8y ago
  > And I wouldn't call it 'really secure', I'd say it's just as secure as any other client side secret. Only if you store the cert in a file, but you can store it on a smartcard (e.g. Yubikey) or a TPM.
pat2man 8y ago
Webauthn is coming to browsers. It has a much easier UI than traditional client certs.
sgtcodfish 8y ago
At the BBC we use mutual TLS extensively in our cloud-deployed applications, across a lot of developers and different teams, for both service-to-service and developer-to-service auth (all devs get a client cert). It works well for a lot of use cases, not least because most things are doing a TLS handshake anyway when communicating. That means that adding client certs into the mix isn't much of an overhead and you can avoid another authentication/authorization step if your CA hierarchy is well managed and you can trust that a cert which says "Joe Bloggs" is actually Joe's cert. Also obviously it avoids any 3rd parties, like you said! That said, it only really works for us because a lot of apps are deployed through a centralised tool which adds relatively short-lived certificates to deployments and then automatically redeploys things before their certs expire. That ensures that certs stay valid. We also have a solution to handle revocation in the event that a cert is compromised, which is a massive pain. So if you spend the time to set everything up it's pretty great, but the cost of setting it up is quite high. You'll also run into problems where you want to use some tool X but it doesn't support mutual TLS and you're forced to either find a different tool or hack in support if that's an option. A big example of missing support is things like the Application Load Balancer in AWS (or equivalents in other clouds) - they tend not to support mutual auth, which means that you can't really use them and you're forced to use a more traditional load balancer with TLS passthrough and then terminate TLS somewhere else.
z3t4 8y ago
I think there was a standard to generate keys in the browser, etc, but it got deprecated. The problem with certificates is moving them between devices. There are so many formats.
commandlinefan 8y ago
I've used client certificate authentication before, and two big problems present themselves. The first is the opacity of the error messages - if something goes wrong, you usually get a message like "SSL Error #128" with no further information to be found, even if you're reading log files on the server side, because TLS is implemented by low-level libraries. That could be solved with better library support, but the TLS standard (at least until TLS 1.2) makes it difficult to include detailed error information - sometimes for good reason, since too much info can itself be a security hole! The second problem I always run into is that certificates expire with no warning and no option to "ignore this error until I get a chance to fix it". Of course you and I can understand why this happens, but users generally don't.

LeonM 8y ago

I did use client side certificates for a while. It's a real pain to get the certificate installed, as it is different per OS and browser. And I wouldn't call it 'really secure', I'd say it's just as secure as any other client side secret.

Boulth 8y ago
> And I wouldn't call it 'really secure', I'd say it's just as secure as any other client side secret. Only if you store the cert in a file, but you can store it on a smartcard (e.g. Yubikey) or a TPM.

pat2man 8y ago

Webauthn is coming to browsers. It has a much easier UI than traditional client certs.

sgtcodfish 8y ago

At the BBC we use mutual TLS extensively in our cloud-deployed applications, across a lot of developers and different teams, for both service-to-service and developer-to-service auth (all devs get a client cert). It works well for a lot of use cases, not least because most things are doing a TLS handshake anyway when communicating. That means that adding client certs into the mix isn't much of an overhead and you can avoid another authentication/authorization step if your CA hierarchy is well managed and you can trust that a cert which says "Joe Bloggs" is actually Joe's cert. Also obviously it avoids any 3rd parties, like you said! That said, it only really works for us because a lot of apps are deployed through a centralised tool which adds relatively short-lived certificates to deployments and then automatically redeploys things before their certs expire. That ensures that certs stay valid. We also have a solution to handle revocation in the event that a cert is compromised, which is a massive pain. So if you spend the time to set everything up it's pretty great, but the cost of setting it up is quite high. You'll also run into problems where you want to use some tool X but it doesn't support mutual TLS and you're forced to either find a different tool or hack in support if that's an option. A big example of missing support is things like the Application Load Balancer in AWS (or equivalents in other clouds) - they tend not to support mutual auth, which means that you can't really use them and you're forced to use a more traditional load balancer with TLS passthrough and then terminate TLS somewhere else.

z3t4 8y ago

I think there was a standard to generate keys in the browser, etc, but it got deprecated. The problem with certificates is moving them between devices. There are so many formats.

commandlinefan 8y ago

I've used client certificate authentication before, and two big problems present themselves. The first is the opacity of the error messages - if something goes wrong, you usually get a message like "SSL Error #128" with no further information to be found, even if you're reading log files on the server side, because TLS is implemented by low-level libraries. That could be solved with better library support, but the TLS standard (at least until TLS 1.2) makes it difficult to include detailed error information - sometimes for good reason, since too much info can itself be a security hole! The second problem I always run into is that certificates expire with no warning and no option to "ignore this error until I get a chance to fix it". Of course you and I can understand why this happens, but users generally don't.