How HTTPS works: the TLS handshake explained step by step

You type a URL with https:// and in under 200 milliseconds your browser and the server have negotiated an encrypted channel no intermediary can read or tamper with. That process — the TLS handshake — combines asymmetric and symmetric cryptography so elegantly it deserves to be understood line by line. It also explains why certificates expire, what exactly TLS 1.3 is, and why plain HTTP has no remaining excuse.

The problem it solves

Without TLS, three attacks are trivial for anyone with network access (a public WiFi, your ISP, an exit node):

• Eavesdropping: reading passwords, tokens or content in cleartext.
• Tampering: modifying responses — injecting scripts, changing prices, redirecting downloads.
• Impersonation: running a fake server that answers for the legitimate domain.

TLS eliminates all three with two complementary mechanisms: channel encryption and server authentication via certificates.

The two kinds of cryptography and their division of labor

The design's genius lies in using each tool for what it's best at:

Asymmetric cryptography (RSA or, today almost always, ECDHE over elliptic curves) solves the impossible problem: how to agree on a shared secret over a channel everyone can listen to. It is mathematically expensive, so it only runs for a few milliseconds at the start.

Symmetric cryptography (AES-256-GCM or ChaCha20-Poly1305) encrypts all real traffic. It is hundreds of times faster but requires both parties to already share a key — which is exactly what the asymmetric step just achieved.

The handshake is essentially "spend the expensive stuff for 100 ms to manufacture the cheap key used for the rest of the session".

The TLS 1.2 handshake, step by step

TLS 1.2 remains the majority protocol and its flow illustrates each piece best:

1. ClientHello: the browser sends supported TLS versions, its list of acceptable cipher suites and — crucially — a 32-byte random value.
2. ServerHello + Certificate: the server picks suite and version, sends its own random value and its X.509 certificate chain: the domain certificate signed by an intermediate CA, signed in turn by a root.
3. Certificate verification: the browser validates the signature up to a root in its trust store, checks validity dates, that the domain name matches the SAN (Subject Alternative Name), and queries whether the certificate has been revoked (CRL/OCSP).
4. Key exchange: with ECDHE, client and server perform Diffie-Hellman operations over elliptic curves using their private keys and ephemeral parameters. They derive the same secret without ever transmitting it.
5. Finished: both sides compute a MAC of everything said so far with the derived keys. If anyone tampered in between, MACs mismatch and the connection dies right here.

From that moment every record travels encrypted and authenticated with AES-GCM: confidentiality and integrity together.

What changes in TLS 1.3

TLS 1.3 (2018) rewrote the handshake around three goals:

• Fewer round trips: with session reuse the browser can send useful data after one round trip (or zero with 0-RTT for reconnects).
• Mandatory forward secrecy: it removed RSA key transport and every static exchange. Session keys always come from ephemeral material (the "E" in ECDHE). If the server's private key leaks tomorrow, yesterday's captured traffic stays unreadable.
• Minimal surface: only a handful of secure suites remain. RC4, badly-used CBC, TLS compression (the CRIME attack source) and renegotiation are dead.

Why certificates expire

A certificate asserts "this public key belongs to this domain", signed by an authority. Expiry limits damage from leaked keys and forces rotation. Let's Encrypt runs a 90-day cycle designed for automation via ACME (Certbot and friends): renewing should be invisible, not an annual project.

If you visit a site with an expired, mismatched or self-signed certificate, the browser blocks because any of those states breaks the impersonation guarantee — the third attack from the beginning becomes possible again.

What HTTPS does not protect

Knowing the limits prevents false confidence:

• That you visit it: the destination domain is visible in DNS and in the SNI field of the handshake (ECH/Encrypted Client Hello is mitigating this). HTTPS encrypts content, not the fact you connect.
• That the site is honest: phishing with a valid Let's Encrypt certificate shows a green padlock. The padlock means an encrypted channel to something; not that the something is who it claims to be.
• Malware inside the content: encrypting transport does not sanitize payload.

How to audit it on your own site

What a serious check reviews: enabled protocols (only TLS 1.2 and 1.3), negotiated suite, certificate validity and SAN, complete chain (a missing intermediate works on some browsers and fails on others), HSTS enabled and 301 redirection from HTTP. Our SSL Checker analyzes your domain and delivers exactly that report; to inspect a certificate's internal fields, the Certificate Decoder dumps them in readable form.

FAQ

Does HTTPS slow down my site? Handshake cost is tens of milliseconds, amortized with session resumption and keep-alive. HTTP/2 — which practically requires HTTPS — usually makes sites faster than their HTTP/1.1 non-TLS equivalent.

Do I need a dedicated IP for HTTPS? Not since SNI (Server Name Indication), which serves multiple TLS domains behind one IP. Let's Encrypt issues free certificates, so HTTPS' real cost is zero.

Can I see my app's HTTPS traffic for debugging? Yes, but not on the wire: inside your own process. DevTools sees plaintext after decryption; mitmproxy requires installing its CA on the device and only works against apps without certificate pinning.

Check your domain's TLS state now with the SSL Checker, free and no sign-up.