Handshake protocol 2 – Transport Layer Security at a Glance
The ClientHello and ServerHello messages contain information to establish a shared secret, the handshake secret. If DHE or ECDHE key agreement is used, the ServerHello message includes the key˙share TLS extension with Alice’s secret Diffie-Hellman share. Moreover, Alice’s share must be from the same group as one of the shares presented by Bob.
If, on the other hand, key establishment based on PSKs is used, ServerHello contains the pre˙shared˙key extension to indicate which of the keys already shared by Alice and Bob shall be used. Alternatively, PSK and DHE or ECDHE can be used together. In this case, ServerHello contains both TLS extensions.
At this point, the handshake secret is already known to Alice and she can derive a number of related keys from it. For example, Alice can protect all following handshake messages she sends to Bob using the so-called server˙handshake˙traffic˙secret, and client˙application˙traffic˙secret˙N protects application data sent from Bob to Alice. This nicely illustrates the best practice we described in Chapter 3, A Secret to Share stating that every cryptographic key should be used for one task only.
Next, Alice sends Bob two messages containing the server parameters. The first message, EncryptedExtensions, contains responses to ClientHello extensions wich are unrelated to cryptographic settings. The second message, CertificateRequest, contains parameters for the client certificate – if Alice and Bob want to perform certificate-based client authentication (the message is otherwise omitted).
3. Finally, in the authentication phase, the server Alice and, optionally, the client Bob authenticate themselves, confirm the established shared key, and verify the integrity of the handshake. To achieve this, Alice and Bob exchange authentication messages.
The Certificate message contains the endpoint’s certificate and certificate-related TLS extensions for that certificate. If certificate-based authentication is not used, the server omits this message. Likewise, if the server does not send a CertificateRequest message, the Certificate message is omitted by the client.
The CertificateVerify message contains a digital signature of the entire handshake protocol execution. The signature is computed using the private key that matches the public key in the Certificate message. This illustrates a cryptographic best practice to explicitly ensure that both communicating parties Alice and Bob sent and received identical data, thereby adding yet another protection layer against man-in-the-middle attacks.
At the end of the TLS handshake, the server sends the Finished message containing a MAC over the entire handshake. This confirms the newly established secret key and binds the endpoint’s identity to it.
The client replies with its own authentication messages and the Finished message. After the Finished message from the client – and assuming the signature and MAC checks were successful – Alice and Bob derive the keys needed to protect the application data.
Figure 6.7 shows the complete default TLS 1.3 handshake as specified in RFC 8446. The asterisk (*) denotes optional TLS messages or extensions that are transmitted or omitted based on previous messages or chosen cryptographic parameters. Curly braces denote messages secured using shared secret keys derived from [sender]˙handshake˙traffic˙secret. Finally, square brackets ([]) denote messages secured using shared secret keys derived from the secret called [sender]˙application˙traffic˙secret˙N.
Figure 6.7: Full TLS 1.3 handshake