Short answer
A TLS handshake is the opening negotiation that establishes an encrypted connection. The client proposes protocol versions and cipher suites (Client Hello), the server selects and sends its certificate (Server Hello), the two perform a key exchange that gives them a shared secret without ever sending it across the wire, and from that both sides derive the symmetric session keys that encrypt the rest of the conversation. In TLS 1.2 this takes two round-trips; in TLS 1.3, one.
Why a handshake at all?
Symmetric encryption is fast, but it requires both parties to hold the same key. The problem is agreeing on that key over a network where anyone can listen in. The handshake solves exactly that: it uses asymmetric cryptography and a key-exchange algorithm to agree on a shared secret, while simultaneously verifying that the server is who it claims to be via its certificate. The result is a channel that is both confidential and authenticated. The difference between the protocols themselves is covered in SSL vs TLS.
The message sequence in TLS 1.2
The classic handshake is a two-round-trip exchange. Simplified, the order looks like this:
Client Server | ---- ClientHello ----------------> | versions, cipher suites, random, SNI | <--- ServerHello ----------------- | chosen version + cipher, random | <--- Certificate ----------------- | server's certificate chain | <--- ServerKeyExchange ----------- | (ECDHE) server's ephemeral public key | <--- ServerHelloDone ------------- | | ---- ClientKeyExchange -----------> | client's ephemeral public key | ---- ChangeCipherSpec ------------> | "from now on I encrypt" | ---- Finished --------------------> | verify handshake integrity | <--- ChangeCipherSpec ------------ | | <--- Finished -------------------- | | ==== encrypted application data == |
Note that the Finished messages contain a hash of the entire handshake so far. If an attacker had tampered with any single message along the way (for instance, trying to downgrade the protocol), the hashes would not match and the connection is aborted.
Step 1 — Client Hello
The client opens with a list of what it supports: TLS versions, a prioritised list of cipher suites, a random number (the client random) and a set of extensions. The most important extension is SNI (Server Name Indication), which tells the server which domain the client wants — essential when many sites share one IP. More on that in SNI explained.
Step 2 — Server Hello and certificate
The server picks the highest common protocol version and a single cipher suite from the client's list, sends its own random number (the server random) and delivers its certificate chain. The client validates the chain up to a trusted root, checks the expiry date, that the name matches the SNI, and — depending on configuration — revocation status. If the server does not send the full chain, validation fails in many clients; that is the most common practical handshake failure.
Step 3 — Key exchange
This is where the shared secret is agreed. Modern TLS uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): each side generates an ephemeral key pair, they exchange the public parts, and both can now independently compute the same shared secret — without that secret ever being sent. Because the key pair is ephemeral (discarded after the connection), you get Perfect Forward Secrecy: even if the server's private key leaks later, past traffic cannot be decrypted.
Step 4 — Session keys and Finished
From the shared secret plus the two random values, both sides derive the same symmetric session keys via a key-derivation function. From this point they switch to symmetric encryption (fast), and the Finished messages confirm that nobody has tampered with the handshake. The chosen cipher suite determines exactly which algorithms are used for key exchange, authentication, encryption and integrity.
TLS 1.3: a single round-trip
TLS 1.3 redesigned the handshake. The client makes an educated guess at the key-exchange parameters and already sends its ephemeral public key in the Client Hello. The server can therefore reply with everything needed at once, and application data can flow after just one round-trip (1-RTT) instead of two:
Client Server | ---- ClientHello + key_share ----> | | <--- ServerHello + key_share ----- | + Certificate + Finished (encrypted) | ---- Finished -------------------> | | ==== encrypted application data == |
For repeat visits TLS 1.3 even offers 0-RTT, where the client sends data already in its very first packet. At the same time TLS 1.3 removed static RSA key exchange and a range of weak algorithms — which is why every TLS 1.3 connection provides forward secrecy. The full comparison: TLS 1.2 vs TLS 1.3.
| Aspect | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Round-trips | 2 (1 on resumption) | 1 (0 on resumption) |
| Forward secrecy | Only with ECDHE | Always |
| Static RSA key exchange | Allowed | Removed |
See your own handshake
You can inspect a handshake live. The output shows the negotiated protocol and cipher:
openssl s_client -connect example.com:443 -servername example.com
Look for Protocol : TLSv1.3 and Cipher : TLS_AES_256_GCM_SHA384. If instead you want to test why a handshake fails, we have a dedicated guide: "SSL handshake failed".
How CertControl watches the handshake
A handshake typically fails for predictable reasons: the server offers obsolete protocols (TLS 1.0/1.1), is missing an intermediate in the chain, or serves a certificate close to expiry. CertControl scans your endpoints from the outside, negotiates a real handshake against each one, and reports the chosen protocol and cipher, the completeness of the chain and the days to expiry — so you see the problems before your users hit them.
Frequently asked questions
How long does a TLS handshake take?
Typically a few milliseconds on top of the network round-trip time. TLS 1.2 needs two round-trips before data can flow, TLS 1.3 only one — which is why TLS 1.3 connections feel noticeably faster, especially on high-latency mobile networks.
What is the difference between the handshake and the encryption itself?
The handshake is the opening negotiation that agrees keys and verifies identity using asymmetric cryptography. Once it finishes, the application data itself is encrypted symmetrically with the negotiated session keys, which is far faster.
What is a session key?
A temporary symmetric key derived during the handshake and used to encrypt all application data in the connection. It exists only for that one session and is discarded afterwards.
Why is the server's certificate sent during the handshake?
So the client can verify the server's identity and obtain its public key. The client validates the certificate chain up to a trusted root and checks that the name matches the domain it is connecting to.
What does 1-RTT mean in TLS 1.3?
1-RTT (one round-trip time) means client and server need only a single back-and-forth exchange before encrypted application data can be sent. TLS 1.2 required two. On resumed connections TLS 1.3 can even achieve 0-RTT.
Can a handshake be downgraded by an attacker?
The handshake is protected against downgrade attacks: the Finished messages contain a hash of the whole exchange, so any tampering along the way makes the hashes fail to match and the connection is aborted.