TLS (non-anonymous) Handshake requires the Server to sign the ServerKeyExchange message so that the Client can authenticate the Server using the public key present in the Server Certificate.

However, TLS Handshake with Client Authentication requires the Client to hash all previous handshake messages, digitally sign it & send this signature in the CertificateVerify message. The Server then verifies this signature using the public key present in the Client Certificate.

https://tools.ietf.org/html/rfc5246#section-7.4.8

It is understandable that ClientKeyExchange & CertificateVerify are 2 separate messages because Client Authentication is optional. But, is there any specific reason for having the Client sign over all previous messages instead of just signing the ClientKeyExchange (like the Server does) and sending the signature in CertificateVerify?

  • Server auth is actually optional. DH_anon and ECDH_anon omit signature from ServerKX -- but they are usually disabled, often prohibited, and sometimes not implemented at all because this does not provide the normally expected security. SRP has a similar option not to PKC-authenticate, although SRP already implies a shared secret. PSK only uses a shared secret, and Kerberos uses its own authentication or none. Which leaves me at least as mystified as you :-) – dave_thompson_085 Aug 13 '16 at 12:38

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.