HTTPS and the TLS Handshake

Difficulty: Advanced

Question

What is HTTPS and how does the TLS handshake work? Walk through TLS 1.2 and TLS 1.3, and explain what forward secrecy is.

Answer

HTTP by itself sends everything in plain text, so anyone on your Wi-Fi or along the path can read passwords or modify pages. HTTPS is simply HTTP running inside a TLS tunnel, and TLS gives three guarantees: confidentiality (nobody can read the data), integrity (nobody can tamper with it undetected) and authentication (you are really talking to the server you intended). Getting all three requires clever mixing of asymmetric and symmetric cryptography, and that is the heart of the handshake.

The problem TLS solves: the two parties have never met, and yet they must agree on a shared secret over a channel that an attacker can watch. Symmetric encryption (AES) is fast but needs a shared key. Asymmetric encryption is slow but lets you establish trust and exchange keys. So TLS uses asymmetric techniques only during the handshake to authenticate the server and derive a shared session key, and then uses fast symmetric encryption for all the actual data.

TLS 1.2 handshake, simplified: the client sends ClientHello with supported TLS versions, cipher suites and a client random. The server replies with ServerHello (chosen suite and server random), its certificate chain, and for ECDHE key exchange, its ephemeral public key signed with its certificate's private key. The client validates the certificate (trusted CA signature, hostname match, not expired, not revoked), verifies the signature, generates its own ephemeral key share, and both sides compute the same pre-master secret using Diffie-Hellman without ever transmitting it. Each derives the session keys from the pre-master secret plus both randoms. Both send Finished messages, encrypted with the new keys, containing a hash of the whole handshake so tampering is detected. That takes two round trips before application data.

TLS 1.3 (2018) streamlines this to one round trip. The client guesses the key exchange group and sends its key share in the very first ClientHello. The server responds with ServerHello plus its key share, and everything after that, including the certificate, is already encrypted. Legacy insecure options are removed: RSA key transport, static Diffie-Hellman, CBC ciphers, RC4, SHA-1, compression, and renegotiation. Only AEAD ciphers such as AES-GCM and ChaCha20-Poly1305 remain. TLS 1.3 also supports 0-RTT resumption, where a returning client sends data immediately using a pre-shared key, at the cost of replay risk, so it should only be used for idempotent requests.

Forward secrecy, also called perfect forward secrecy, is a property that comes from using ephemeral Diffie-Hellman keys (DHE or ECDHE). The session keys are derived from temporary keys that are thrown away after the session. Even if an attacker records all your encrypted traffic today and steals the server's private key next year, they cannot decrypt the old sessions. Old-style RSA key exchange lacked this: the pre-master secret was encrypted with the server's long-term public key, so one key leak would expose all recorded history. TLS 1.3 makes forward secrecy mandatory.

Extras for depth: SNI (Server Name Indication) is an extension in ClientHello that tells the server which hostname the client wants, allowing many HTTPS sites on one IP, though it leaks the hostname in plain text unless Encrypted Client Hello is used. ALPN negotiates HTTP/2 or HTTP/3 inside the handshake. Session resumption via tickets skips the full handshake for repeat connections. HSTS tells browsers to always use HTTPS for a domain and prevents downgrade attacks. Common failure causes: expired certificate, hostname mismatch, missing intermediate certificate, and client clock skew.

Code examples

Inspecting a TLS handshake with openssl

$ openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | egrep 'Protocol|Cipher|subject|issuer|Verify'
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
 subject=CN = www.example.org
 issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1
    Verify return code: 0 (ok)

Shows the negotiated version, AEAD cipher, and that the chain verified against a trusted CA.

Key points

• TLS uses asymmetric crypto to agree on a key and symmetric crypto for data.
• TLS 1.2 needs 2 round trips; TLS 1.3 needs 1 (0 for resumption).
• ECDHE gives forward secrecy; TLS 1.3 requires it.
• SNI reveals the hostname unless ECH is used.

Concepts covered

HTTPS, TLS Handshake, Key Exchange, Certificates, Forward Secrecy