3 ms·

Client certs have a few advantages over API keys. First of all, it gives the server more certainly that the other side of the TLS connection is the authenticat

by thayne 1y ago

Client certs have a few advantages over API keys. First of all, it gives the server more certainly that the other side of the TLS connection is the authenticated user, and not a MitM[1]. Secondly, if the message is intercepted, the secret key isn't compromised, and the secret key can be kept more secure than an API key that has to be sent with every request. It also allows the signing party to be different from the verifying party. To be fair JWTs using asymmetric crypto also have this property. And client certs, often using a private CA, are frequently used for server-to-server communication. You are right about browsers not having good support for client certs, but there isn't any fundamental reason that couldn't be better. As far as public key infrastructure, I agree that for client certs it isn't quite as useful as it is for server certs, but there are situations where it could be useful. Suppose a server for example.org makes a request to example.com. With a client cert signed using PKI, example.com can know that the request actually came from example.org, without having any previous establishment of a trust relationship between the two parties. That is a relatively niche use case, but I could see it being useful in federated protocols. [1]: or at least if it is a MitM, it has access to the private key for the cert.

7bit 1y ago
> First of all, it gives the server more certainly that the other side of the TLS connection is the authenticated user, and not a MitM[1]. The certificate (or rather the privkey) is -- like the token -- a secret that only the client and the server should know. Certificate-based authentication and token do protect equally from MITM. And MITM attacks are equally possible when cert or token auth is being done. The only thing where cert based auth got the client shines is that you don't have to move a new token over the wire, initially.
- thayne 1y ago
  Consider if a malicious actor is able to fool the client into using http instead of https, or is able to sign arbitrary certs, because they control a CA that is trusted by the client (as in some corporate firewalls for example, or malware installed a bad CA). Now the client sends the auth token as part of the request, the MitM can intercept it, and get the auth token, and the server has no way of knowing there is a third party involved. But with a client cert, intercepting the request gets you nothing. You don't have the secret key, so there isn't any way for you to complete the TLD handshake with the server. > The certificate (or rather the privkey) is -- like the token -- a secret that only the client and the server should know. No, the server doesn't need to know the privkey at all, it only needs to know the public key of the CA that signed the cert.

by thayne 1y ago

7bit 1y ago

> First of all, it gives the server more certainly that the other side of the TLS connection is the authenticated user, and not a MitM[1]. The certificate (or rather the privkey) is -- like the token -- a secret that only the client and the server should know. Certificate-based authentication and token do protect equally from MITM. And MITM attacks are equally possible when cert or token auth is being done. The only thing where cert based auth got the client shines is that you don't have to move a new token over the wire, initially.

thayne 1y ago
Consider if a malicious actor is able to fool the client into using http instead of https, or is able to sign arbitrary certs, because they control a CA that is trusted by the client (as in some corporate firewalls for example, or malware installed a bad CA). Now the client sends the auth token as part of the request, the MitM can intercept it, and get the auth token, and the server has no way of knowing there is a third party involved. But with a client cert, intercepting the request gets you nothing. You don't have the secret key, so there isn't any way for you to complete the TLD handshake with the server. > The certificate (or rather the privkey) is -- like the token -- a secret that only the client and the server should know. No, the server doesn't need to know the privkey at all, it only needs to know the public key of the CA that signed the cert.