TLS 1.3 Handshake Explainer
Transport Layer Security 1.3 creates a private, authenticated channel between applications over an untrusted network. A typical browser and server use the handshake to agree on cryptographic algorithms, establish shared secrets, authenticate the server’s identity, and confirm that neither side saw a different transcript. Once those checks succeed, they protect application records with symmetric encryption and integrity protection. TLS does not decide whether a website is honest or an application request is safe; it verifies the presented identity under the configured trust rules and prevents outsiders from reading or silently changing the protected traffic.
The client begins with a ClientHello. It lists supported protocol options, carries a random value, names acceptable cipher suites, and normally includes one or more ephemeral key shares. It may also indicate the server name and the application protocol it wants, such as HTTP. The server responds with a ServerHello selecting compatible settings and providing its own key share. Using an ephemeral Diffie-Hellman exchange, both sides independently calculate the same shared secret without sending that secret across the network. The transcript and a defined key schedule turn it into separate handshake and application keys.
After ServerHello, most remaining handshake messages are encrypted. The server sends parameters, its certificate chain, and a CertificateVerify signature made with the certificate’s private key. The client checks whether the certificate names the intended host, is within its validity period, chains to a trusted certificate authority, and is permitted for the required use. It also verifies the signature over the handshake transcript. That signature proves possession of the private key and binds the identity to this particular exchange rather than merely presenting a copied certificate.
Each side then sends a Finished message computed from the handshake secret and the transcript. A valid Finished value demonstrates that both endpoints derived matching secrets and observed the same prior messages. Any alteration to negotiated settings, key shares, or certificates changes the transcript and causes verification to fail. After the client’s Finished message, both parties can use application traffic keys. TLS 1.3 removes several older algorithms and handshake patterns, reducing the number of combinations that implementations must secure and normally completing a new handshake in one round trip.
Session resumption can make a later connection faster. The server gives the client a ticket associated with a resumption secret, and the client proves possession on a future handshake. The endpoints derive fresh traffic keys instead of simply reusing the previous connection’s keys. Some configurations permit zero-round-trip early data, but that data lacks ordinary replay protection. Applications should accept it only for repeatable operations and must handle rejection. Forward secrecy also depends on using fresh ephemeral key exchange so compromise of a long-term certificate key does not automatically reveal recorded past sessions.
A strong protocol can still be deployed poorly. Certificate validation can fail through an incorrect clock, missing intermediate certificate, wrong hostname, expired certificate, or untrusted authority. Endpoints need secure random number generation, current cryptographic libraries, protected private keys, and careful error handling. TLS does not conceal every observable fact: network addresses, timing, traffic volume, and sometimes the requested server name may remain exposed depending on surrounding protocols. Nor does a padlock guarantee that content is truthful. TLS 1.3’s focused promise is narrower: authenticate the selected peer according to a trust policy, derive fresh shared keys, verify the complete negotiation, and protect subsequent records against eavesdropping and undetected alteration.
Traffic keys are not used forever. TLS derives separate secrets for each direction, so compromise or misuse in one context is less likely to contaminate another. Either endpoint can request an update that produces new application traffic keys without rebuilding the whole connection. Record sequence numbers and authenticated encryption make modification or reordering detectable within the protocol’s rules. Clean connection closure also carries authenticated intent, helping an application distinguish an orderly end from a network interruption. These details turn one successful handshake into a maintained secure channel rather than a permanent key pasted onto an unstructured byte stream.
TLS 1.3 combines an ephemeral key exchange, certificate authentication, a transcript-bound signature, and Finished checks to derive protected traffic keys. Key terms include ClientHello, ServerHello, key share, certificate chain, CertificateVerify, Finished, transcript, traffic key, resumption, and forward secrecy.
The signature proves that the server controls the certificate’s private key and binds that proof to the current handshake transcript. A copied public certificate alone cannot authenticate an attacker who lacks the private key.
With fresh ephemeral key exchange, later theft of a server’s long-term certificate key does not by itself reveal the traffic keys from previously recorded sessions. It does not protect a live endpoint that is already compromised.
Explore more "Explainers"
Discover additional explainers across politics, science, business, technology, and other fields. Each explainer breaks down a complex idea into clear, everyday language—helping you better understand how major concepts, systems, and debates shape the world around us.