TLS Handshake
Watch the complete TLS 1.3 handshake unfold step by step. See ClientHello, ServerHello, key exchange, certificate verification, and how encrypted communication is established.
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) is the cryptographic protocol that secures communication over the internet, powering HTTPS. TLS 1.3 is the modern standard, offering faster connection times and tighter security than its predecessors by completing the handshake in a single round trip.
Mental Model
Think of a TLS 1.3 handshake like two lockbox collectors setting up a private trade. First, the buyer (Client) sends a lockbox (ClientHello) with their padlock open and a list of key designs they support (Key Share). The seller (Server) picks a key design, locks their own open padlock to the box (ServerHello), and sends it back. Both can now compute the same combination (shared secret) locally without ever exchanging keys. The seller then puts their business license (Certificate Chain) in the box to prove their identity, and both snap the locks shut. After ServerHello, handshake messages are protected; the ordinary ClientHello, including SNI unless ECH is used, is a separate visibility boundary.
Components and Why They Exist
Client Browser
Initiates the connection, selects crypto parameters, and verifies server identity. Generates random values, offers cipher suites and key shares, and validates the server certificate chain. In the demo, observe the client initiating the handshake by sending its key share in the ClientHello packet.
Eavesdropper (Passive Observer)
Represents insecure network hops or attackers listening in on the transmission medium. Sniffs packets on the network; can view plain text metadata at first, but is blocked once encryption is active. In the demo, observe that after the key exchange phase, the eavesdropper only sees encrypted random bytes.
Web Server
The host destination serving the application and proving its identity to connecting clients. Negotiates protocol versions, supplies its own key shares, and returns its signed certificate chain. In the demo, watch the server authenticate itself and transmit encrypted session parameters to the client.
Edge Cases and Misconceptions
- Certificates Do Not Encrypt Data: A common misconception is that the server’s TLS certificate is used to encrypt the application traffic. In reality, the certificate is used strictly for authentication (verifying the server’s identity). The actual data encryption is done using symmetric keys derived via the Diffie-Hellman key exchange.
- Perfect Forward Secrecy (PFS): TLS 1.3 mandates Diffie-Hellman key exchange to ensure forward secrecy. Even if an attacker records all encrypted traffic and later steals the server’s private certificate key, they cannot decrypt the recorded traffic because the session keys were generated ephemerally and never transmitted.
- 0-RTT Replay Vulnerability: TLS 1.3 supports 0-RTT session resumption to send data in the first packet. However, because this packet can be intercepted and resent by an attacker, 0-RTT requests must be restricted to idempotent actions (like GET requests) to prevent replay attacks.
Common Questions
What is the difference between TLS 1.2 and TLS 1.3 handshakes?
TLS 1.2 requires two network round trips (2-RTT) to establish a connection, as key exchange and certificate verification happen sequentially. TLS 1.3 speculatively sends key shares in the first message (ClientHello), reducing the handshake to a single round trip (1-RTT).
What is a 'Key Share' in TLS 1.3?
A key share contains the client's public keys generated for specific, supported elliptic curve groups. By sending these in the ClientHello, the server can immediately calculate the shared secret upon choosing the curve, saving a round trip.
How does TLS 1.3 protect against protocol downgrade attacks?
The server embeds a specific, hardcoded signature value in the server random bytes of its ServerHello when negotiating TLS 1.3. If a middleman attempts to alter the ClientHello to force a lower version (like TLS 1.2), the client will detect the mismatch in the server random signature and terminate the connection.
What is 0-RTT Session Resumption?
When a client connects to a server for the second time, it can use a pre-shared key (PSK) derived from the first session to encrypt application data in the very first packet (ClientHello). However, 0-RTT traffic is vulnerable to replay attacks unless protected by the application layer.
Why did TLS 1.3 remove static RSA key exchange?
Static RSA key exchange does not provide Perfect Forward Secrecy. If the server's private key were compromised in the future, any historical traffic encrypted with it could be decrypted. TLS 1.3 deprecated RSA key exchange in favor of ephemeral Diffie-Hellman (ECDHE).
How does the client verify that the server owns the certificate?
The server signs a hash of the entire handshake transcript using its private key (CertificateVerify step). The client uses the server's public key (found in the certificate) to verify this signature. Since only the actual owner of the certificate possesses the corresponding private key, this proves ownership.
What is a Cipher Suite in TLS 1.3?
A cipher suite is a combination of cryptographic algorithms used to secure the connection. In TLS 1.3, cipher suites are simplified and only define the symmetric cipher and hash algorithm (e.g., TLS_AES_256_GCM_SHA384), as the key exchange and signature algorithms are negotiated independently.