PingAuthorize

TLS handshakes

The process of negotiating the TLS is referred to as the handshake.

Although the exact process depends on the TLS version that is ultimately chosen, the following steps represent the basic components of a TLS 1.2 handshake:Flowchart showing the process of a TLS 1.2 handshake

TLS processing steps

  1. The client sends a hello message that provides the server with the following information:

    • Highest supported version of the TLS protocol

    • The cipher suites that the client uses

    • Set of extensions with additional information:

      • The address that the client uses to communicate with the server

      • The signature algorithms and elliptic curves that the client supports

      • Whether the client supports secure renegotiation

  2. The server returns a server hello message that provides the client with the following information:

    • The TLS protocol version that the server uses

    • The cipher suite that the server selects

      The server can also provide its own extensions to the client.

  3. The server sends a certificate message that provides its certificate chain to the client.

  4. The server can optionally send a server key exchange message with additional information that the client might need to securely derive the same symmetric encryption key that the server generates.

  5. The server can optionally send a certificate request message that asks the client to present its own certificate chain to the server.

  6. The server sends a server hello done message to inform the client that it has completed its hello sequence.

  7. The client can optionally send a certificate message to the server with its own certificate chain.

    The client sends a certificate message only when the server initially sends a certificate request. If the client receives such a request, it can refuse to, and probably will not, send a certificate chain. The server decides whether to require a client certificate chain. In LDAP, the server commonly asks the client to present a certificate, but continues with TLS negotiation even if the client does not present one. This approach supports authentication methods like SASL EXTERNAL, in which a client uses the certificate chain that it presents during TLS negotiation as proof of its identity.

  8. The client derives a symmetric key to use for the remainder of the encrypted processing, and sends a client key exchange message to the server. The client key exchange message includes the information that the server needs to generate the same key. Only the client and server know the value of the key, even if another entity can observe the communication that passes between the client and the server.

  9. If the client presents a certificate chain to the server, it also sends a certificate verify message to prove that the private key for the certificate is included at the head of the chain.

  10. The client sends a change cipher spec message to the server, which informs the server that the client will use the agreed-upon symmetric key to encrypt everything else that it sends to the server.

  11. The client sends a finished message to the server to indicate that it has completed its portion of the handshake.

  12. The server sends a change cipher spec message to the client, which informs the client that the server will use the agreed-upon symmetric key to encrypt everything else that it sends to the client.

  13. The server sends a finished message to the client to indicate that it has completed its portion of the handshake.

TLS 1.3 uses a different handshake sequence that can require only a single round-trip to exchange the necessary information between the client and the server. TLS 1.2 requires two round-trips. To accomplish this task, TLS 1.3 tries to guess the type of key agreement that the server wants to use, and sends the relevant information to the server up front instead of waiting to hear from the server.

Because an extra round of communication between the client and server is eliminated, the server finishes its portion of the negotiation before the client. The server must assume that the client trusts its certificate chain. Because the server might log a successful negotiation only to discover late, through a TLS alert, that the client rejected the certificate, this approach might complicate certain types of troubleshooting.