10.5.5 Certificates and TLS authentication messages
Recall that at the end of the TLS 1.3 handshake, client Bob and server Alice exchange authentication messages shown in bold in Figure 10.7. The same set of messages is used whenever client Bob and server Alice perform certificate-based authentication (authentication based on a pre-shared key happens as a side effect of the key exchange).
Figure 10.7: Full TLS 1.3 handshake with authentication messsages shown in bold
The set of authentication messages is composed of the Certificate, CertificateVerify, and Finished messages, as shown in Listing 10.4. These messages are protected using keys derived from client˙handshake˙traffic˙secret and server˙handshake˙traffic˙secret. Upon receiving server Alice’s authentication messages, client Bob responds with his authentication messages.
Listing 10.4: Authentication messages in TLS handshake
enum {
X509(0),
OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} CertificateType;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
struct {
opaque verify_data[Hash.length];
} Finished;
The Certificate message contains either Alice’s or Bob’s certificate and any per-certificate extensions. This message is omitted by server Alice if certificate-based authentication is not used in that TLS session and by client Bob if Alice did not send the CertificateRequest message (which would indicate that Alice wants Bob to authenticate himself using his digital certificate).
The CertificateVerify message carries the digital signature over the entire TLS handshake. The signature is generated using the private key that corresponds to the public key in the respective Certificate message. As an example, the signature in Alice’s CertificateVerify message is generated using Alice’s private key. Alice’s corresponding public key is contained in the certificate that Alice sends to Bob in her Certificate message. If certificate-based authentication is not used, this message is omitted.
The Finished message contains a so-called Message Authentication Code (MAC) over the entire TLS handshake. We will cover message authentication codes in detail in the next chapter on Hash Functions and Message Authentication Codes. For now, it suffices to know that they can be used as cryptographically secure checksums.
With this, Alice and Bob use the Finished message to verify that all handshake messages sent by Bob were not manipulated en route and were indeed received by Alice, and vice versa. As a result, the Finished message provides key confirmation, binds the identities of Alice and Bob to the exchanged secret keys, and, if the pre-shared key mode is used, authenticates the TLS handshake.
More generally, the Finished message illustrates a best practice in the design of cryptographic protocols where at the end of the protocol, the communicating parties verify that they had the same view of their interaction, for example, that no other messages were received except those that were actually sent and that no messages were lost.