1

In mutual TLS, during client-authentication phase, a client proves its identity to the server by sending its client certificate (Certificate message). Additionally, it signs all previous handshake messages using its private key and sends the resulting hash (CertificateVerify message). Server uses this hash to validate client's ownership of the certificate.

What is the security benefit of the doing CertificateVerify validation above? How cert can be compromised while key can't?

A typical key storage/management logistics for client key+cert is "bundled". Usually, when server issues client certificate to a particular client - it supplies key+cert (often bundled into a single P12 or PFX file, or PEM file with both parts concatenated), and all client APIs (OpenSSL, curl, Node.js request, etc.) expect both key and cert to be supplied. Therefore, a client reasonably deals with key and cert local storage/protection the same way.

Since they're typically bundled - what benefit/reason there is for key-verification of a cert? Why supplying just cert would not be good enough?

Official definition and reasoning (which is not convincing to me, per the above):

EDIT (to emphasize the client cert is self-signed by the server):

It is clear that for well-known-CA signed client certificates, key is indeed required. That's because in such case - client's cert is publicly known.

However, in most real-life cases I saw - the server is a well-known entity, while clients are not (or the server doesn't care if they are, and still issues, and expects to get, self-signed certs of its own). Since clients are not well-known entities - arranging a well-known-CA registration for each client - is not practical. In other words, the server issues the key+cert. And then - the question is - is there still any security benefit of supplying key-verified hash, in addition to cert during mTLS client auth?

Does it only exist in the protocol to cover the case when client cert is issued by a well-known-CA, i.e. for cases when client cert is protected differently than key? Or there's some solid reason for key in self-signed scenario as well?

Improve this question
7
  • I see a lot of interesting answers, but note that the whole idea of PKI the public key infrastructure is that the public key / certificate is public and can be distributed to anyone. If it wasn't you could just keep a secret key between two parties. So you cannot authenticate using just the certificate because anyone could have the certificate. Commented Jan 27, 2021 at 23:02
  • @MaartenBodewes, yes, I understand it in the general sense of things. I added a clarification that my question is for the self-signed client cert case Commented Jan 28, 2021 at 11:14
  • You can still use the self signed cert case between mutliple senders/receivers, and eavesdropping a connection is enough to retrieve the certificate. The certificate cannot be protected against eavesdropping yet because that's just what you need the authentication for in the first place - you can always perform a man-in-the-middle before the certificate is send. So if you use a self-signed cert or one from a CA is inconsequential. Commented Jan 28, 2021 at 15:12
  • @MaartenBodewes, MITM is impossible here, I guess, because the connection is protected by server-side TLS before I send my cert, so eavesdropping of my cert is impossible. Yes, you can say that irresponsible client can pass this cert to others, but irresponsible client can also pass PK to others, so what's the diff? Thanks Commented Jan 28, 2021 at 16:43
  • There is no requirement to protect public certificates, so that's different from distributing a private key that's supposed to be private. They may show up in logs,and you know that there is at least one certificate that is known another side: the server. And how are you going to share the certificate securely in the first place? Commented Jan 28, 2021 at 16:55

3 Answers 3

Reset to default
6

I think you need to do some reading on what a certificate is. At it's core, a certificate is an attestation from the Certificate Authority (CA) to bind together the following information:

  • Name (DN or SAN)
  • Public key

Think of it like a driver's license that "binds together" your name, birthdate and photo. Imagine you hand your ID to a bouncer; alright, so they know that somebody has that name and birthdate, but to prove that it's you, you have to show your face and let the bouncer verify that it matches the photo. Mailing someone a photocopy of a driver's license does not actually prove that you are the person named on the ID.

Similarly, when you authenticate to a server using a client certificate, you are proving your identity in the following way:

  • Provide a public key.
  • Perform an operation that could only have been done with the matching private key, thus proving that you are the owner of that public key.
  • Provide a CA-signed certificate binding that public key to your name, thus proving that you are the person named in that certificate.

Update addressing comments

Yes, you really need to use the private key, even if the client cert is self-signed, even if it's issue by a private CA.

Sending a client cert without using the private key is like showing your ID to a bouncer without showing your face. You need to use the private key in order to prove that you are the owner of the public key in the certificate. In digital security we call this a "replay attack" because if all you needed to do was show your certificate, then once you've shown it to one server, that server could impersonate you to another server (or an admin of that site could impersonate you). Public key cryptography solves this because you only share your public key (which is inside the certificate) and keep the matching private key to yourself. If you're not using any of the cryptography in a certificate, then why go through the effort? Why not have users log in with username/password; that would be much simpler and get you the same security properties.

Improve this answer
10
  • Mike, thanks, I know how certs and PKI work in general. My question was what is the benefit of PK in this specific scenario. I see you wrote a detailed guidance about a similar case here: security.stackexchange.com/a/168802/249969, this verifies that using self-signed certs is an OK approach, but it doesn't give a justification/reasoning for the use of PK in this scenario. Why it's still needed? Commented Jan 28, 2021 at 11:10
  • @Borka With all due respect, I don't think you do understand how certs work. Sending a client cert without using the private key is like showing your ID to a bouncer without showing your face. You need to use the private key in order to prove that you are the owner of the public key in the certificate. Commented Jan 28, 2021 at 14:35
  • Mike, using your analogy, my ID is "glued" with my face, there's no physical way to steal my ID without also stealing my face (key + cert are bundled in a single PEM file I pass to curl). I never send cert to anyone except cert-issuing server (why should I?), and this server cannot present it to another server because that another server won't be able to validate it anyway because it was issued (and CA-ed) only by this server. MITM stealing of client cert is avoided by first TLS part (server-cert based encryption). What am I missing here? Commented Jan 28, 2021 at 16:38
  • @Borka ... I don't know where to start. I think you completely mis-understand how certificates work. Yes, you pass privkey + cert to curl, curl most certainly does not pass the priv key to the server. Certificates are intended to be public information (the thing inside it is called a public key after all). You may choose to keep your certificate as a secret, but that is not what they are designed for. Commented Jan 28, 2021 at 17:53
  • 1
    @Borka I think what you're saying is that doing TLS client auth with a self-signed client cert is completely useless (no security). Yes, I agree with that. Don't do that! Commented Jan 28, 2021 at 18:10
0

You want to treat the certificate like a password: the issuing authority, the legitimate server and the client would all have to keep it secret. This has many downsides, the biggest of which is that the server needs to keep a big database with all the clients' secrets. This database needs to be replicated and backed up so that clients don't lose access if the server is destroyed (hardware failure, operator error, etc.), but it also needs to be kept secret (against database leaks, password leaks, etc.). If multiple servers need to authenticate the same client, the security of the password is at the mercy of the weakest client.

Using asymmetric cryptography solves this and other problems. The certificate contains the public key, plus additional metadata indicating who issued that public key and in what way the issuer vouches for the client. The certificate doesn't need to be kept particularly secret: if it leaks, this may compromise the client's privacy, but it doesn't let anyone impersonate the client.

Anyone can have the certificate, but that doesn't let them impersonate the client. To impersonate the client, you need the corresponding private key. Only the client needs to have the private key. The issuing authority had to have a copy (if it wasn't generated on the client itself), but it could delete it after sending it to the client. The server does not need to know the client's private key. It doesn't even need to know the client's public key: usually, all it needs to know is that the certificate is signed by the appropriate certificate authority. Asymmetric cryptography allows the server not to store a secret value for each permitted client, and public-key infrastructure (certificates) allow the server not to even store a public value for each permitted client.

Improve this answer
1
  • Thanks, Gilles, I added a clarification that it's a self-signed cert case. In the general PKI sense the reasoning for PK is clear, but my question is about a very specific scenario. What is the reason (is there any?) for PK in client cert auth for self-signed client certs. Commented Jan 28, 2021 at 11:12
0

Other answers describe general ideas behind PKI and cert validation, but do not directly answer the question. After some research, I hope I found an answer. There is a very specific reason why CertificateVerify message with key-signed hash-validation is needed, also in case client cert is originally produced and self-signed by the server:

Client Certificate message is not encrypted(*)

(* in TLS 1.2, see note about TLS 1.3 below)

And since it's not encrypted - even if cert is kept/protected on the client side the same way as the key - the cert, when it's sent by the client as part of the handshake - is accessible to man-in-the-middle. This makes server-self-signed client cert case identical to a public-CA-signed client cert in a sense that client cert is indeed public regardless how well the client keeps it protected.

Here it is from TLS 1.2 spec (https://www.rfc-editor.org/rfc/rfc5246#section-7.3): TLS 1.2 handshake Theoretically, it could be possible to encrypt Certificate as well, but it's not done in the TLS 1.2 spec. My personal, uneducated guess - due to a high cost of RSA encryption, and since in a more generic case (public-CA-issued client cert) - key-verification is still needed, so it wouldn't simplify/improve anything in generic mechanism, while adding costly RSA encryption during the handshake phase.

Interestingly, TLS 1.3 spec mandates handshake messages (including Certificate message) to be encrypted, but according to TLS 1.3 spec - the encryption at this stage is unauthenticated, so client cert transmission can still be accessed by main-in-the-middle, therefore cert should be protected by a mandatory PKI verification (CertificateVerify). The verification mechanism in TLS 1.3 is somewhat different, though (https://www.rfc-editor.org/rfc/rfc8446#section-2): TLS 1.3 handshake

With TLS 1.3, the key exchange and cert-verification mechanisms are decoupled, therefore this question becomes irrelevant. To the best of my understanding - TLS 1.3 with client cert (regardless of the issuer) - requires key verification because there is nothing in TLS 1.3 key-exchange itself that protects from client being impersonated by man-in-the-middle.

Comments/corrections are welcome.

P.S.: some excellent links doing proper drill-down into the details of a handshake, both TLS 1.2 and TLS 1.3:

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.