How TLS Works: The HTTPS Handshake Explained
TLS encrypts web traffic using a handshake that authenticates the server with a certificate and agrees on fresh keys. See how HTTPS keeps connections private.
Transport Layer Security (TLS) is the protocol that puts the S in HTTPS. It protects data travelling between two programs, most often a browser and a web server, by providing three things: confidentiality (eavesdroppers cannot read the data), integrity (tampering is detected), and authentication (you are really talking to the server you intended). It does this with a handshake that authenticates the server and agrees on secret keys, followed by fast symmetric encryption of everything that follows. The current version is TLS 1.3, published in 2018.
Why does the web need TLS?
Without encryption, anyone along the path — a Wi-Fi operator, an internet provider, an attacker on the same network — can read or alter your traffic, including passwords, cookies, and the pages you see. HTTP and HTTPS covers the web side; TLS is the encryption layer underneath. It normally runs on top of a TCP connection, after the three-way handshake has finished, and it also protects email servers, messaging apps, and many APIs.
The protocol began as SSL, created at Netscape in the mid-1990s: SSL 2.0 in 1995 and SSL 3.0 in 1996. TLS 1.0 followed in 1999, then 1.1 in 2006, 1.2 in 2008, and 1.3 in 2018 (RFC 8446). The name SSL lives on in everyday speech, but no SSL version is considered secure, and TLS 1.0 and 1.1 were formally deprecated in 2021.
The TLS 1.3 handshake step by step
- ClientHello: the client sends the TLS versions and cipher suites it supports, a random number, the name of the site it wants, and a key share, its half of an ephemeral Diffie–Hellman key exchange (usually on an elliptic curve).
- ServerHello: the server picks a cipher suite and sends its own key share. Both sides can now compute the same shared secret, which an eavesdropper cannot derive from the public values that crossed the wire. This is the idea behind public-key cryptography. From this point the rest of the handshake is encrypted.
- Certificate and proof: the server sends its certificate chain and a signature over the handshake so far, proving it holds the private key that matches the certificate. It finishes with a Finished message that authenticates the whole exchange.
- Client finish: the client checks everything, sends its own Finished message, and both sides start encrypting application data with keys derived from the shared secret.
TLS 1.3 needs a single round trip before data can flow, down from two in TLS 1.2. Connections that resume a previous session can send early data immediately, at the cost of some replay risk.
How does a certificate prove identity?
A certificate binds a domain name to a public key and is signed by a certificate authority (CA). Browsers and operating systems ship with a list of trusted root CA certificates. A server presents its own certificate together with intermediate certificates, and the client checks every signature up the chain to a trusted root, confirms that the domain name matches, and checks that the certificate has not expired. Each signature is computed over a hash of the certificate, so changing even one character invalidates it. If any check fails, the browser shows a warning.
Certificates used to be expensive and manual. Since Let's Encrypt began issuing free, automated certificates in 2015 and 2016, HTTPS has become the default across most of the web. The industry has also agreed to shorten maximum certificate lifetimes in stages, down to 47 days by 2029, so that mistakes and key compromises expire faster.
Forward secrecy and the symmetric phase
TLS 1.3 requires an ephemeral key exchange: new keys are generated for each connection and thrown away afterwards. If an attacker steals the server's long-term private key years later, they still cannot decrypt traffic they recorded earlier. This property is called forward secrecy. Once the keys are agreed, bulk data is protected with symmetric authenticated encryption such as AES-GCM or ChaCha20-Poly1305. Public-key mathematics is used only during the handshake, because it is far slower than symmetric ciphers.
What TLS does not do
TLS does not hide everything. Network observers can still see the IP addresses you connect to, and often the site name sent in the handshake, unless the newer Encrypted Client Hello extension is in use. Name lookups through DNS are a separate step with their own privacy options. TLS also cannot protect a compromised device. And the padlock means only that you have an encrypted connection to the named domain, not that the owner of the domain is honest. Even so, TLS is the reason payments, logins, and private messages can safely cross a hostile network.
Tags
cryptography encryption http security tls