typical TLS 1.2 connection – Transport Layer Security at a Glance – Entity Authentication

typical TLS 1.2 connection – Transport Layer Security at a Glance

6.5.2 A typical TLS 1.2 connection

The following figure shows the interplay of the TLS subprotocols in a typical TLS connection until TLS 1.2. The TLS 1.3 handshake is much more compact by eliminating one entire roundtrip from the earlier version.

Figure 6.5: Overview of a typical TLS message flow without client authentication (up to version 1.2, adapted from [146])

Note that the record protocol does not appear in Figure 6.5. This is because the record protocol is underlying all of the messages shown there. The first messages (until the first ChangeCipherSpec) are transferred in cleartext, and messages after that are encrypted.

Now, let’s take a more detailed look at the messages in Figure 6.5.

Algorithm negotiation

In the very first message in Figure 6.5, ClientHello, the client proposes to the server a list of supported sets of algorithms for key establishment, digital signatures, encryption, and message authentication. These sets of algorithms are called cipher suites.

The ClientHello message also contains the protocol version, a random number, and optionally a session ID in case of session resumption (see Section 6.5.3). The server answers with its own ServerHello message, which contains a specific cipher suite chosen from the list, a SessionID, and a random number of its own. This concludes the algorithm negotiation phase. Note that all messages so far have been exchanged over an insecure channel.

While unauthorized changes in the cipher suites by an attacker can be detected afterward by way of the Finished message (see Section 6.5.3), so-called version rollback attacks, where the client and server are forced to use lower protocol versions than they actually support, are possible (see Chapter 20, Attacks on the TLS Handshake Protocol).

Key establishment

The key establishment phase starts with a Certificate message, which provides a copy of the server’s public key to the client. The ServerKeyExchange message can take different forms, depending on the specific key exchange protocol algorithm chosen by the server (it might even be omitted altogether, but that is a very unusual choice nowadays). Without delving into the cryptographic details, the ServerKeyExchange message is typically a kind of Diffie-Hellman public key that has been dynamically generated for this session and that has been signed by the server in order to provide authenticity. The signature can be validated by the client using the public key from the previous Certificate message.

After the client has sent its own ClientKeyExchange message, algorithms and a shared secret are negotiated between the client and server, and the key establishment phase is concluded. The initial shared secret is called the PreMasterSecret (PMS). Both parties now derive further encryption and message authentication keys from the PreMasterSecret by using so-called Key Derivation Functions (KDFs).

Server authentication

After having agreed on a cipher suite and a shared key, bulk encryption can start. This is triggered by the ChangeCipherSpec protocol message. The next message, Finished, is the first encrypted handshake message and it is a very important one because it contains a key-dependent hash value of all previous handshake messages. This allows the server to verify whether the previous handshake messages, especially the ClientHello and ServerHello messages, have been tampered with. Without this retrospective integrity protection, an attacker would be able to downgrade the cipher suites negotiated at the beginning of the handshake. Moreover, the Finished message enables the server to check whether both parties have successfully derived the same keys. After the server has sent its own Finished message, the client can do the same. Moreover, by proving knowledge of the correct key for the Finished message, the server also proves that it knows the private key corresponding to the ephemeral key sent in the ServerKeyExchange message. Therefore, the server authenticates by way of a public-key-based challenge-response protocol as described in Section 5.5.4, Challenge-resonse using public-key cryptography.

Client authentication

Client authentication within the TLS handshake (as opposed to client authentication via some higher-layer protocol) must be explicitly requested by the server by means of the CertificateRequest message sent after ServerKeyExchange (not shown in Figure 6.5).

In response, the client will send its certificate and, if necessary, a chain of higher-order certificates (see Chapter 10, Digital Certificates and Certificate Authorities, for details) within the ClientCertificate message, which is followed by ClientKeyExchange. In order to finalize client authentication, another CertificateVerify message is needed, in which the client digitally signs the transcript of all previous handshake messages (see Chapter 9, Digital Signatures, for more information on digital signatures).

Note that client authentication is rarely requested by the server, lest the client is burdened by certificate management.

After the authentication phase, application data is protected: first, it is tunneled into the Application data subprotocol, which is in turn encrypted by the record protocol.