TLS 1.3 vs TLS 1.2 Handshake
Compare the TLS 1.3 and TLS 1.2 handshake processes side-by-side. Understand 1-RTT negotiation, encrypted post-ServerHello messages, and forward-secret keys.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Transport Layer Security (TLS) has evolved to optimize both security and performance. The transition from TLS 1.2 to TLS 1.3 represents a major milestone in networking, cutting connection setup latency in half and encrypting handshake metadata by collapsing the handshake from two round trips to one.
Mental Model
Think of a TLS handshake like establishing a secure line of credit. In TLS 1.2, you make one call to agree on a secret language (Client/ServerHello), a second call to send and verify ID cards (Certificate), and a third call to confirm everything works before you buy anything (ChangeCipherSpec/Finished) — taking two full round trips. In TLS 1.3, you send a key share along with the first message. After ServerHello selects the shared secret, the server sends its certificate and the remaining handshake messages under handshake protection; the ordinary ClientHello SNI is a separate privacy concern. You compute the secret code locally, confirm the ID, and immediately start buying things—saving one entire round trip.
Components and Why They Exist
Client (Browser)
Initiates secure handshakes and negotiates protocols to establish a secure channel. Generates keys and ciphers lists, sends key shares in ClientHello, and verifies server certificates. In the demo, observe the client sending the initial ClientHello packet along with speculative key shares in the TLS 1.3 lane.
Server
Authenticates the domain identity and agrees on encryption protocols with the client. Chooses cryptographic algorithms, generates key shares, and sends the encrypted certificate chain in TLS 1.3. In the demo, watch the server reply with its handshake key share and certificate, completing the key exchange in one round trip.
Network Lifelines (RTT Tracks)
Visualizes the chronological time delay (Round Trip Time) between client and server actions. Plots step intervals vertically to contrast the 1-RTT of TLS 1.3 against the 2-RTT of TLS 1.2. In the demo, watch how packets travel down the timeline tracks, showing TLS 1.3 finishing much earlier.
Edge Cases and Misconceptions
- Symmetric Keys are Negotiated Ephemerally: In both protocols, the heavy data payload is encrypted using symmetric key cryptography (e.g. AES). The asymmetric handshake keys are used only to safely negotiate this transient symmetric session key.
- TLS 1.3 handshake confidentiality has a boundary: TLS 1.3 encrypts the Certificate and later handshake messages after ServerHello. The ordinary ClientHello, including SNI, is still visible unless ECH is negotiated, so certificate encryption does not by itself hide the requested hostname.
- Obsolete Cryptographic Algorithms: TLS 1.2 supports weak algorithms like MD5, SHA-1, RC4, and static RSA key exchange. TLS 1.3 deprecated these entirely, only supporting secure AEAD ciphers and forward-secure Diffie-Hellman groups.
Key Differences Summary
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake Latency | 2-RTT | 1-RTT |
| Certificate Privacy | Plaintext (Leaked metadata) | Encrypted (Secure metadata) |
| Cipher Negotiation | 2 round trips | 1 round trip |
| Obsolete Ciphers | Supported (static RSA, custom DH) | Removed (PFS-only DH, AEAD-only) |
Common Questions
Why is TLS 1.3 faster than TLS 1.2?
TLS 1.3 performs key negotiation in a single round-trip (1-RTT) by combining the key share exchange with the ClientHello, whereas TLS 1.2 requires two round-trips (2-RTT) before application data can be sent.
How does TLS 1.3 protect client privacy better than TLS 1.2?
TLS 1.3 encrypts the handshake messages sent after ServerHello, including the server Certificate. The ordinary ClientHello SNI remains visible to the network unless Encrypted ClientHello (ECH) is used, so certificate confidentiality should not be described as complete hostname privacy.
What is a Key Share in TLS 1.3?
A key share is the client's public key for an ephemeral Diffie-Hellman key exchange, sent in the ClientHello. This allows the server to immediately derive the shared secret in its first response.
What does perfect forward secrecy (PFS) mean and why does TLS 1.3 enforce it?
Perfect Forward Secrecy ensures that if a server's long-term private key is compromised in the future, it cannot be used to decrypt past sessions that were recorded. TLS 1.3 enforces PFS by deprecating static RSA key exchanges and requiring ephemeral Diffie-Hellman key exchange for every session.
What are AEAD ciphers and why does TLS 1.3 use them exclusively?
Authenticated Encryption with Associated Data (AEAD) ciphers (like AES-GCM or ChaCha20-Poly1305) provide both confidentiality (encryption) and integrity validation (authenticity) in a single optimized operation. TLS 1.3 removed older, less secure cipher modes that separated encryption and integrity check stages, eliminating vulnerabilities like padding oracle attacks.
Why does a TLS 1.3 handshake fail if there is a 'Key Share Mismatch'?
If the client does not send a key share for the elliptic curve group preferred by the server, the server sends a HelloRetryRequest specifying the desired group. The client must then send a new ClientHello with the matching share. This fallback increases the handshake latency to 2-RTT, matching TLS 1.2's latency.
How does TLS 1.3 achieve 0-RTT session resumption?
During a previous connection, the client and server negotiate a Pre-Shared Key (PSK). On subsequent connections, the client encrypts application data using this PSK and sends it immediately with the ClientHello (0-RTT), achieving zero-latency reconnection.
What is the role of the SNI (Server Name Indication) extension?
SNI is a header sent in the ClientHello that tells the server which host name the client is trying to reach. This allows a single IP address to host multiple secure domains, as the server can inspect the SNI to select the correct TLS certificate to return.