What is the TLS handshake?

Short answer

The TLS handshake is the opening step in which the client and the server agree on the connection parameters before encrypted data is sent: with ClientHello, the client announces the versions and cipher suites it supports and the domain it wants to connect to (SNI); with ServerHello, the server makes its selection and sends its certificate; the two sides generate shared session keys with key exchange. The handshake is the most computationally expensive part of TLS. In TR7, the handshake load is monitored from the SSL New Connections (TPS) panel on the SSL tab of the vService Dashboard and is limited by Max. SSL Connections/s in the vService Limits profile.

Where It Is Used in TR7

Where	Field / label	What for
vService → Dashboard → SSL tab	SSL New Connections (TPS), SSL Concurrent Connections, SSL Session Reuse	New SSL connections per second, open SSL connections and the rate of sessions resumed from the cache
Load Balancer → Profiles (L4-L7 Behavior Sets) → vService Limits	Max. SSL Connections/s, Max. Total SSL Connections	Limiting the rate of new SSL connections and the number of open SSL connections
Certificates & PKI → TLS Security Profiles	Min. SSL Version, Cipher Algorithms, Curve/ECDHE	The version, cipher suites and curves accepted in the handshake
Load Balancer → Conditions (Policy Match)	SSL Version, SSL Cipher, SSL SNI Info	A decision based on the values agreed on in the handshake; SSL SNI Info matches only on an L7 TCP vService that does not terminate SSL (passthrough)

How Does It Work?

The full handshake in TLS 1.3 (RFC 8446):

1. ClientHello: The client sends the versions, cipher suites and key exchange groups it supports, its key share, and the SNI and ALPN extensions.
2. ServerHello: The server selects the version, the cipher suite and the group, and sends its own key share; from this point on, the messages are encrypted.
3. Certificate, CertificateVerify, Finished: The server sends its certificate and the signature that proves it has its private key; the client verifies them, and the handshake is completed with Finished.

In TLS 1.3, the full handshake is a single round trip; in TLS 1.2, it takes two round trips. Clients that have connected before can skip the full handshake with session resumption (What is TLS session resumption?).

Common Misconceptions

• "The cost of TLS is in the encrypted data transfer." The main cost is in the handshake on each new connection; keep-alive and session resumption reduce this cost.
• "If the handshake fails, the certificate is broken." The client and the server failing to find a common version or cipher suite also makes the handshake fail.
• "The handshake is completely unencrypted." In TLS 1.3, the messages after ServerHello (including the certificate) are encrypted; ClientHello and the SNI in it, on the other hand, travel in the clear.

How it is done in the documentation

• Dashboard · SSL Tab
• vService Limits · Max. SSL Connections/s
• TLS Security Profiles · TLS Settings (Frontend & Backend)

Related questions

• What is a cipher suite?
• What is SNI (Server Name Indication)?
• What is TLS session resumption?
• What is SSL offloading (termination), and how is it set up?