TLS Handshake

How the TLS 1.3 handshake works

The TLS 1.3 handshake takes 1 round-trip (down from 2 in TLS 1.2) for fresh connections, or 0 RTT for resumed sessions. Here's the flow for a fresh connection:

1. ClientHello. Client sends supported TLS versions, cipher suites, ECDHE key share (its public ephemeral key), Server Name Indication (which domain it's connecting to), and supported extensions. Crucially, TLS 1.3 sends the key share immediately — no negotiation round needed.
2. ServerHello. Server picks the cipher suite, sends its ECDHE public key share, signs the handshake transcript with its certificate's private key, and sends the certificate chain. All of this in one flight. The server now knows the shared secret (derived from both ECDHE shares); the client will know it after this packet arrives.
3. Finished. Both sides exchange Finished messages encrypted with the freshly derived session keys, confirming the handshake completed without tampering. Application data can flow immediately.

By the end of the second packet (server → client), both sides have the session key and can encrypt/decrypt application data. That's the 1-RTT bound.

TLS 1.2 vs TLS 1.3

	TLS 1.2	TLS 1.3
Released	2008	2018
Handshake RTTs (fresh)	2	1
0-RTT resumption	No	Yes (with replay risk)
Cipher suite count	~300 supported	5 allowed
Forward secrecy	Optional (ECDHE)	Mandatory
RSA key exchange	Allowed	Removed
Authenticated encryption	Optional (AES-GCM)	Mandatory (AEAD)
Encrypted server cert	No	Yes — protects identity
Vulnerabilities of older versions	BEAST, CRIME, Lucky 13 (mostly fixed)	Designed to avoid them

TLS 1.3 was a major redesign — not an incremental update. It removed every cryptographic option that had been broken or weakened over the previous decade: static RSA, MD5, SHA-1, RC4, CBC mode, compression. The result is a much smaller attack surface and a much faster handshake.

The certificate chain explained

A server's certificate is a public statement: "this public key belongs to example.com." For the client to trust it, the certificate must be signed by an authority the client already trusts. The chain works like this:

example.com cert (signed by) → DigiCert TLS RSA SHA256 (intermediate)
                          (signed by) → DigiCert Global Root CA (in browser trust store)

The client verifies each signature working up the chain. Roots are pre-installed in operating systems and browsers — Apple, Microsoft, Mozilla, Google curate these trust stores. If any link in the chain is invalid or expired, or the chain doesn't end in a trusted root, the connection fails with a certificate error.

Modern best practice: don't sign with the root directly. Roots stay offline (cold storage); intermediates are signed by the root and used to sign individual server certs. If an intermediate is compromised, you revoke just that intermediate, not the root. Let's Encrypt issues hundreds of millions of certs annually via this model.

Cipher suites in TLS 1.3

Suite	Bulk cipher	Hash	Used by
TLS_AES_256_GCM_SHA384	AES-256-GCM	SHA-384	High-security defaults
TLS_AES_128_GCM_SHA256	AES-128-GCM	SHA-256	Default for most servers
TLS_CHACHA20_POLY1305_SHA256	ChaCha20-Poly1305	SHA-256	Mobile devices without AES hardware acceleration
TLS_AES_128_CCM_SHA256	AES-128-CCM	SHA-256	IoT / constrained devices
TLS_AES_128_CCM_8_SHA256	AES-128-CCM (8-byte tag)	SHA-256	Smaller authentication tag for low-bandwidth

The Curve25519 (X25519) ECDHE group is the modern default for key exchange. P-256 and P-384 NIST curves are also widely supported.

When TLS handshake details matter

• Web performance. The 1-RTT TLS 1.3 handshake combined with TCP's 1-RTT setup means HTTPS starts producing data after 2 RTT — vs 3 RTT under TLS 1.2. On a 100ms-RTT link, that's 200ms saved per fresh connection. HTTP/3 + QUIC combines TCP and TLS into one handshake, dropping it to 1 RTT total.
• Service-to-service authentication (mTLS). When microservices need to authenticate each other, mTLS provides cryptographic identity without passwords. Kubernetes service meshes (Istio, Linkerd) use mTLS extensively.
• Certificate management at scale. Each TLS connection requires a valid certificate. Let's Encrypt's free 90-day certs require auto-renewal; commercial CAs offer 1-year certs at a price. Automating renewal (cert-manager on Kubernetes, certbot on Linux) is the modern operational practice.
• Key rotation and incident response. Forward secrecy means past sessions stay safe even if a key leaks. Without it (RSA key exchange in old TLS), one stolen private key compromises every recorded session. Always use ECDHE.

Famous TLS-era attacks (mostly historical)

• POODLE (2014). Padding-Oracle attack on SSL 3.0. Forced the deprecation of SSLv3.
• Heartbleed (2014). Bug in OpenSSL's heartbeat extension allowed reading server memory remotely. 17% of the internet was vulnerable; widespread certificate revocations followed.
• BEAST (2011). Browser exploit against TLS 1.0's CBC mode. Mitigated by mode selection workarounds; fully fixed in TLS 1.1+.
• FREAK / Logjam (2015). Attacks against export-grade weak ciphers that should have been long removed but weren't. Forced removal of all "EXPORT" cipher suites.
• SLOTH (2016). Length extension and collision attacks against MD5 and SHA-1 in TLS. Forced removal of those hashes from the handshake.

The pattern: every weak cryptographic primitive eventually becomes a CVE. TLS 1.3's design philosophy is to allow only primitives believed to be secure for the foreseeable future and remove everything else — a stark contrast to TLS 1.2's "negotiate any of 300+ options" approach.

Inspecting a TLS handshake with curl

# See the certificate chain and protocol details
curl -v https://example.com 2>&1 | grep -E 'TLS|certificate|SSL|subject|issuer'

# Force TLS 1.3 only
curl --tlsv1.3 --tls-max 1.3 https://example.com

# Show the full handshake with openssl
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Common TLS issues and pitfalls

• Expired or self-signed certificates. Browsers will refuse to connect. Production servers must auto-renew (Let's Encrypt + certbot) before expiration. Self-signed certs are fine for internal testing, never for public services.
• Hostname mismatch. The certificate's subject or Subject Alternative Names (SANs) must include the hostname being connected to. Wildcard certs (*.example.com) cover one level; multi-domain SANs cover specific hosts.
• Mixed-content warnings. An HTTPS page loading HTTP resources triggers browser warnings or blocks. Always use HTTPS for sub-resources, or use protocol-relative URLs (//example.com/foo).
• Weak cipher suites. Servers must reject deprecated ciphers (RC4, 3DES, NULL, EXPORT) regardless of what clients propose. Tools like SSL Labs grade configurations; A+ requires excluding all weak suites.
• Replay attacks against 0-RTT. Don't enable 0-RTT for state-changing requests. The standard mitigation is to allow 0-RTT only for idempotent HTTP methods (GET, HEAD).
• Certificate transparency requirements. Modern browsers require certificates to appear in CT logs. Commercial CAs handle this automatically; private CAs running pre-CT-logging may produce certs that browsers reject.