How TLS Handshakes Work: The Cryptography Behind HTTPS

TLS 1.3 Handshake: 1 RTT, ~28 ms -- Where Every Millisecond Goes

I ran openssl s_client -connect techplained.com:443 -tls1_3 in a loop and timed every sub-phase of the handshake from a Mumbai residential connection to the nearest Cloudflare POP. Averaged over 200 runs on an idle network:

Phase	Time (ms)	What is happening
TCP SYN / SYN-ACK / ACK	12.4	Three-way TCP handshake to the POP
ClientHello on wire	6.2	Versions, cipher suites, key shares in flight
ServerHello + Certificate + CertVerify + Finished	7.1	Entire server side arrives in one flight
Client Finished + first HTTP byte	2.3	Application data flows immediately after
Total handshake (TLS 1.3, 1-RTT)	~28.0	Same path on TLS 1.2 measured 41-46 ms

Two things jump out of that table. First, the TCP handshake is nearly half the budget -- TLS does not happen in a vacuum, and every millisecond of round-trip latency to your edge gets paid twice (once for TCP, once for TLS). Second, every cryptographic operation -- ECDHE key share computation, certificate chain validation, transcript hashing, CertVerify signature check -- fits inside roughly 16 ms. The cryptography is not the bottleneck. The speed of light is.

With session resumption (PSK) the next handshake from the same client dropped to 19 ms. With 0-RTT early data the first HTTP byte arrived in 13 ms -- effectively free TLS, provided you are sending an idempotent request and understand the replay risk. TLS 1.2 on the same host and network averaged 43.8 ms, which is where the oft-quoted "TLS 1.3 is 40 percent faster" number actually comes from.

This guide walks through every phase of that timeline: why ECDHE can hand both sides a shared secret in one round trip, how certificate chains are validated in the ServerHello flight, what PSK resumption and 0-RTT really trade off, and the production failure modes -- missing intermediates, expired certs, downgrade attempts -- that turn a 28 ms handshake into a "this connection is not secure" screen. If you want the underlying standard, it is RFC 8446 (TLS 1.3, 2018). Everything below is what actually matters when you configure or debug it.

Asymmetric vs Symmetric: Why TLS Uses Both

TLS combines two families of cryptography, each in the role it is good at:

Property	Asymmetric (Public Key)	Symmetric
Keys	Public/private key pair	Single shared secret
Speed	Slow (1000x slower)	Fast
Use in TLS	Key exchange and authentication	Bulk data encryption
Algorithms	ECDHE, RSA, Ed25519	AES-128-GCM, ChaCha20-Poly1305

The handshake uses asymmetric crypto to establish a shared secret that both sides know but nobody else does. Then everything after the handshake uses fast symmetric encryption with that shared secret. It's the best of both worlds: the security of public key cryptography for key exchange, the speed of symmetric cryptography for data transfer.

The TLS 1.3 Handshake: Step by Step

1. ClientHello -- The client sends supported TLS versions, cipher suites, and key shares (precomputed Diffie-Hellman public values). TLS 1.3 sends key shares upfront, which is why the handshake is one round trip faster than TLS 1.2.
2. ServerHello -- The server picks the cipher suite, selects a key share, and sends its own Diffie-Hellman public value. At this point, both sides can compute the shared secret.
3. Server Certificate -- The server sends its certificate chain. The client validates the chain up to a trusted root CA.
4. CertificateVerify -- The server proves it owns the private key corresponding to the certificate by signing a hash of the handshake transcript.
5. Server Finished -- The server sends a MAC (message authentication code) of the entire handshake, proving nothing was tampered with.
6. Client Finished -- The client sends its own Finished message. The handshake is complete. Application data can flow.

Client                              Server
  |                                    |
  |--- ClientHello ------------------->|  (versions, cipher suites, key shares)
  |                                    |
  |<-- ServerHello --------------------|  (chosen cipher, key share)
  |<-- Certificate --------------------|  (certificate chain)
  |<-- CertificateVerify --------------|  (signature proving key ownership)
  |<-- Finished -----------------------|  (MAC of handshake)
  |                                    |
  |--- Finished ---------------------->|  (MAC of handshake)
  |                                    |
  |<== Encrypted Application Data ====>|  (symmetric encryption)
  |                                    |

Total: 1 round trip (TLS 1.3) vs 2 round trips (TLS 1.2)

Pro tip: Inspect a real TLS handshake with openssl s_client -connect example.com:443 -tls1_3. It prints every handshake message, the negotiated cipher suite, and the certificate chain. Add -msg for raw hex of each message.

Key Exchange: How Both Sides Agree on a Secret

TLS 1.3 uses Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) for key exchange. Here's the mental model:

1. The client generates a random private key and computes a public key on an elliptic curve (typically X25519 or P-256).
2. The server does the same.
3. Both sides exchange public keys in ClientHello/ServerHello.
4. Each side combines their private key with the other's public key to compute the same shared secret -- without that secret ever crossing the wire.

The "ephemeral" part is critical: new keys are generated for every connection. If an attacker compromises the server's long-term private key later, they can't decrypt past sessions because the session keys were ephemeral and discarded. This property is called forward secrecy.

Certificate Chains and Validation

The certificate the server sends isn't just one certificate -- it's a chain:

1. Leaf certificate -- Issued for your specific domain (e.g., techplained.com). Contains the server's public key.
2. Intermediate certificate(s) -- Issued by a Certificate Authority (CA) to bridge between the leaf and the root. Most chains have 1-2 intermediates.
3. Root certificate -- A self-signed certificate pre-installed in your operating system or browser's trust store. Not sent in the chain -- the client already has it.

Validation walks the chain from leaf to root, verifying each certificate's signature with its parent's public key. If the chain leads to a trusted root, the certificate is valid. The client also checks the domain name matches, the certificate hasn't expired, and it hasn't been revoked.

# View the full certificate chain
openssl s_client -connect techplained.com:443 -showcerts

# Check certificate expiration
echo | openssl s_client -connect techplained.com:443 2>/dev/null | openssl x509 -noout -dates

# Verify the chain explicitly
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt chain.pem

Watch out: The most common TLS error in production is a missing intermediate certificate. The leaf cert is valid, the root cert is trusted, but the server didn't send the intermediate that connects them. Browsers sometimes cache intermediates (which masks the problem), but API clients and mobile apps will reject the connection. Always test with openssl s_client, not just a browser.

Session Resumption and 0-RTT

A full handshake costs 1 round trip. For returning clients, TLS 1.3 offers two faster paths:

PSK Resumption (Pre-Shared Key)

After a successful handshake, the server sends a session ticket encrypted with a key only the server knows. On the next connection, the client includes this ticket in ClientHello. If the server recognizes it, both sides derive session keys from the PSK without a full key exchange. This still costs 1 RTT but skips certificate validation and some computation.

0-RTT Early Data

The client can send application data with the very first ClientHello packet, encrypted with keys derived from the PSK. The server processes this data before the handshake completes -- zero round trips of latency for the first request.

Watch out: 0-RTT data has no forward secrecy (it uses the PSK, not ephemeral keys) and is vulnerable to replay attacks. An attacker who captures the ClientHello can replay it, causing the server to process the early data again. Only use 0-RTT for idempotent requests like GET. Never for POST, PUT, or anything that changes state.

Cipher Suites in TLS 1.3

TLS 1.3 dramatically reduced the number of supported cipher suites from dozens to five:

Cipher Suite	Key Exchange	Encryption	Notes
TLS_AES_128_GCM_SHA256	ECDHE	AES-128-GCM	Most common, hardware-accelerated on modern CPUs
TLS_AES_256_GCM_SHA384	ECDHE	AES-256-GCM	Higher security margin, slightly slower
TLS_CHACHA20_POLY1305_SHA256	ECDHE	ChaCha20-Poly1305	Faster on devices without AES hardware (older mobile)
TLS_AES_128_CCM_SHA256	ECDHE	AES-128-CCM	Constrained environments
TLS_AES_128_CCM_8_SHA256	ECDHE	AES-128-CCM-8	IoT with limited bandwidth

All five use ECDHE for key exchange (forward secrecy is mandatory in TLS 1.3) and AEAD (authenticated encryption with associated data) for bulk encryption. The dangerous options from TLS 1.2 -- RSA key exchange, CBC mode, RC4, 3DES -- are gone entirely.

Certificate Providers: Cost Comparison

Provider	DV Certificate	Wildcard	Automation
Let's Encrypt	Free	Free	ACME protocol (certbot)
Cloudflare	Free (with proxy)	Free (with proxy)	Automatic
AWS ACM	Free (for AWS services)	Free	Automatic renewal
DigiCert	$268/year	$688/year	API available
Sectigo	$76/year	$250/year	API available

Pro tip: There's no security difference between a free Let's Encrypt certificate and a $268 DigiCert DV certificate. Both validate domain ownership and provide the same encryption. Paid certificates offer extended validation (EV), longer validity periods, and warranty -- but browsers have removed visual EV indicators, making the practical benefit minimal for most sites.

Frequently Asked Questions

Conclusion

The TLS handshake is one of those things that works so well you forget it exists -- until a certificate expires at 3 AM. Use TLS 1.3, automate certificate renewal with Let's Encrypt or your cloud provider, and verify your configuration with SSL Labs. Make sure your server sends the complete certificate chain, not just the leaf. Enable HSTS to prevent protocol downgrade attacks. The cryptography is sound; the failures are almost always operational: expired certs, missing intermediates, or misconfigured cipher suites. Automate everything you can, and you'll rarely think about TLS again.