Network Security

TLS 1.2 vs TLS 1.3 Handshake

Comparing handshake efficiency and security improvements

Laurent Goudet · January 20, 2026 · 4 min read

TLS 1.2

2 round trips - client waits to send key
💻
CLIENT
🖥
SERVER
Round Trip 1
ClientHello
Ciphers, TLS version, client random
No key share yet - must wait for server’s choice
ServerHello
Chosen cipher, server random
Certificate
Server's X.509 cert chain
ServerKeyExchange
Server's ECDH public key + chosen curve
ServerHelloDone

⏳ Client waited to learn which key exchange to use

Round Trip 2
ClientKeyExchange
Now client can send its ECDH public key
ChangeCipherSpec
Switching to encrypted
Finished
Verify handshake integrity
ChangeCipherSpec
Finished
Application Data
HTTP Request
Encrypted with session keys
🔒
2-RTT Handshake
All handshake messages sent in plaintext

TLS 1.3

1 round trip - client sends key upfront
💻
CLIENT
🖥
SERVER
Round Trip 1
ClientHello
Ciphers + key_share extension

🔑 Client’s ECDH key sent upfront (X25519/P-256)

ServerHello
Chosen cipher + server's key_share
Both keys exchanged - can derive secrets now!

🔒 Encrypted from here

EncryptedExtensions
Certificate
Server's X.509 cert chain
CertificateVerify
Signature proving key ownership
Finished
Handshake MAC
Application Data
Finished + HTTP Request
Client can send data immediately!
🔐
1-RTT Handshake
Server messages encrypted, 0-RTT resumption available
FeatureTLS 1.2TLS 1.3
Round trips (full handshake)2-RTT1-RTT
Client key exchangeWaits for server's choiceSent speculatively via key_share
Session resumption1-RTT0-RTT (with caveats)
Handshake encryption✗ Plaintext✓ After ServerHello
Forward secrecyOptional (ECDHE)✓ Mandatory
RSA key exchange✗ Allowed (no PFS)✓ Removed
Cipher suites~40 options5 secure options
Legacy algorithmsMD5, SHA-1, RC4, DES...All removed

🔒

Encrypted messages (TLS 1.3 only)
Why TLS 1.3 saves a round trip

TLS 1.2: The client must wait to see which key exchange algorithm (RSA, DHE, ECDHE) and which curve the server selects before it can send its key. This forces a second round trip.

TLS 1.3: The client sends its key_share speculatively in the first message, typically for X25519 or P-256. Since TLS 1.3 removed RSA key exchange and reduced cipher suites from ~40 to 5, these guesses almost always work.

What if the server doesn’t support the offered curves? The server sends a HelloRetryRequest asking for a different key share, falling back to 2-RTT. This happens in <1% of connections since X25519/P-256 are nearly universal.

Real-World Deployment

Browser support. All modern browsers have supported TLS 1.3 since 2018-2019 (Chrome 70, Firefox 63, Safari 12.1, Edge 79). As of 2026, TLS 1.3 accounts for the majority of HTTPS connections on the public internet. The transition happened faster than any previous TLS version because the performance benefit (one fewer round trip) gave both clients and servers an incentive to upgrade.

The TLS 1.2 long tail. Despite broad TLS 1.3 adoption, TLS 1.2 remains necessary in several contexts. PCI DSS compliance environments often mandate specific cipher suites that map to TLS 1.2 configurations. Enterprise environments with legacy hardware (load balancers, HSMs, IoT gateways) may not support TLS 1.3. The practical advice: configure both TLS 1.2 and 1.3, prefer 1.3, and monitor which version clients actually negotiate.

Planning deprecation. TLS 1.0 and 1.1 are already deprecated (RFC 8996, March 2021). TLS 1.2 deprecation is not imminent but is on the horizon. Track your negotiation logs — if fewer than 1% of clients need TLS 1.2, you can safely require 1.3 and reduce your attack surface. Cloudflare, AWS, and GCP all offer configuration to set minimum TLS versions per endpoint.

TLS 1.3 reduces latency while improving security by removing legacy algorithms and encrypting more of the handshake.

Frequently Asked Questions

How many round trips does TLS 1.3 need vs TLS 1.2?

TLS 1.3 needs 1 round trip (1-RTT) for a full handshake vs 2 round trips (2-RTT) for TLS 1.2. TLS 1.3 also supports 0-RTT session resumption.

Why is TLS 1.3 faster than TLS 1.2?

TLS 1.3 sends the client's key share speculatively in ClientHello, eliminating the extra round trip TLS 1.2 requires to negotiate the key exchange algorithm.

Is TLS 1.3 more secure than TLS 1.2?

Yes. TLS 1.3 removes all legacy algorithms (MD5, SHA-1, RC4, DES), mandates forward secrecy, removes RSA key exchange, and encrypts more of the handshake.

What is 0-RTT in TLS 1.3 and what are the risks?

0-RTT allows clients to send encrypted application data in the very first message when resuming a previous session, using pre-shared keys. The risk is replay attacks: 0-RTT data is not protected by the server's random value, so an attacker can capture and resend it. Servers must only accept 0-RTT for idempotent requests (GET, not POST) and should use single-use session tickets to limit replay windows.

Laurent Goudet

CTO at Freelancer.com

AI agents, networking, and infrastructure at scale

Other deep-dives

© 2026 Laurent Goudet · Bordeaux, France · lepro.dev

vd9714f4