Before a single byte of application data is sent, the client and server must agree on a 'language' (cipher suite), prove their identities, and establish a shared secret. This process, known as the Handshake, is the most computationally expensive part of the connection.
The 1.2 handshake is a multi-step negotiation: 1. ClientHello (Lists supported ciphers). 2. ServerHello (Chooses cipher + sends certificate). 3. Key Exchange (Client sends pre-master secret encrypted with server's public key). 4. Finished (Both sides verify the handshake was not tampered with). This requires two full round-trips (2-RTT).
💡 Notice that in the RSA-based 1.2 handshake, the server's private key is used to decrypt the secret. This is exactly why TLS 1.3 replaced this with Diffie-Hellman to ensure Forward Secrecy.
# Capture the handshake using tcpdump and look for 'Client Hello'
tcpdump -i eth0 -X port 443 | grep 'Client Hello'The 'ClientHello' is sent in cleartext, which is why an attacker can see which ciphers you support. This is a key part of 'fingerprinting' a client (e.g., JA3 fingerprinting).
TLS 1.3 eliminates the back-and-forth. In the ClientHello, the client *guesses* which key exchange algorithm the server prefers and sends its public key share immediately. The server responds with its own share and immediately starts sending encrypted data. This reduces the latency to 1-RTT.
⚠️ If the client's guess is wrong, the server sends a 'HelloRetryRequest'. This falls back to 2-RTT, negating the performance gain.
| Step | TLS 1.2 (Full) | TLS 1.3 (Full) |
|---|---|---|
| Round 1 | ClientHello $ ightarrow$ ServerHello | ClientHello (with Key Share) $ ightarrow$ ServerHello |
| Round 2 | Key Exchange $ ightarrow$ Finished | Encrypted Extensions $ ightarrow$ App Data |
| RTT Count | 2 RTT | 1 RTT |
| Key Agreement | Negotiated after Hello | Sent in first flight |
Performing a full handshake for every single image and CSS file on a webpage would be incredibly slow. Session Resumption allows a client and server who have already met to 'remember' each other. In TLS 1.2, this was done via Session IDs or Session Tickets. In TLS 1.3, this is handled via Pre-Shared Keys (PSK).
If a server uses Session Tickets, it must rotate the 'Ticket Encryption Key' (STEK) frequently. If the STEK is leaked, an attacker can decrypt all sessions that used those tickets.
Verify exercises to earn ★ 160 XP and unlock next lab level.