1

during playing with nginx "ssl_verify_client optional_no_ca" i made the discovery that it does not very the cert signature of a self signed cert. I think this is the intended behaviour, since a cert is supposed to be signed by someone else with mutual trust.

However, if it's merely a file that gets passed around, what prevents someone else from just pretending to have that certificate but not the corresponding private key? It appears to be sent in plaintext on the wire.

specifically the common explanation of the TLS handshake just presents the client cert as a single arrow from client to server without mentioning if the session crypto will include the private key for the cert even if the cert is never validated.

aep
  • 163
  • 4
  • @MechMK1 I think this question is borne from that one. Can you point the OP to the section that deals with the issues they raise? – schroeder Feb 08 '22 at 15:54
  • 3
    In short: the private key is used to sign something specific to the current TLS handshake. The server can then prove the signature. This makes it impossible to use a certificate without having a matching private key. – Steffen Ullrich Feb 08 '22 at 15:58
  • Certs are sent clear in 1.2 and below, but encrypted in 1.3. An attacker can still get a copy of 1.3 server cert (but not key) by just doing a clienthello, but not a 1.3 client cert unless they have a valid cert-and-key for the server name -- which is exactly what PKI is designed to prevent. – dave_thompson_085 Feb 09 '22 at 03:10

1 Answers1

2

The first message from the server to the client (ServerHello) includes a random challenge which changes every time. The client proves that it knows the private key corresponding to its certificate by sending a signature (CertificateVerify) of all the handhsake messages received so far, including the random challenge. A third party that doesn't know the private key can't replay the connection, because the server will send a different random challenge each time.

The mechanism is exactly the same in the other direction. The client's first message also contains a random challenge, and the server must sign data that includes this random input. (That's in cipher suites that use signatures for authentication. In cipher suites that use asymmetric encryption or pre-shared keys, the server instead proves that it can decrypt some data that depends on the random challenge.)

You can see the details of a typical TLS connection in The Illustrated TLS Connection: Every byte of a TLS connection explained. The server's signature is at the end of the “Server Key Exchange” step. This example doesn't use client authentication; if it did, that would be an additional part in “Client Key Exchange” with similar content.

If you want all the details, they're in the specification. The term to look for is CertificateVerify. RFC 5246 §7.3 (TLS 1.2) and RFC 8446 §2 (TLS 1.3) have a summary of the handhske protocol. RFC 5246 §7.4.8 and RFC 8446 §4.4.3 give the content of the CertificateVerify message.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179