The TLS / HTTPS handshake, explained
How two strangers agree on a shared secret in the open — and why the padlock means something.
Explain like I'm 5
When you visit a website with a padlock in the address bar, your computer and that website do a quick secret handshake first. By the end, the two of them share a secret code that nobody watching can figure out — even though the whole conversation happened in the open.
After that, everything they say is scrambled with the secret code. Someone snooping just sees gibberish. And the padlock also means your computer checked the website's ID card to make sure it's really who it claims to be.
HTTPS = HTTP wrapped in TLS, which (1) proves the server is genuine and (2) sets up a shared secret so the rest of the conversation is private and tamper-proof.
Beginner
TLS (Transport Layer Security — the modern name for SSL) provides three guarantees:
- Confidentiality — eavesdroppers can't read the traffic.
- Integrity — traffic can't be silently altered in transit.
- Authentication — you can verify the server really is who it says (and optionally the client too).
Authentication relies on certificates. A certificate is a signed statement binding a domain name to a public key. It's signed by a Certificate Authority (CA) your device already trusts. Your operating system and browser ship with a list of trusted CAs (the trust store).
Asymmetric crypto (public/private keys) is great for proving identity and agreeing a secret, but it's slow. Symmetric crypto (one shared key) is fast. So TLS uses asymmetric crypto briefly during the handshake to establish a shared symmetric key, then switches to fast symmetric encryption for the actual data.
HTTPS is simply HTTP running inside a TLS tunnel, almost always on port 443.
Intermediate
Here is a classic TLS 1.2 handshake. The two sides negotiate parameters, the server proves its identity, and both derive the same session keys.
- ClientHello — the client offers the TLS versions and cipher suites it supports, plus a random number.
- ServerHello — the server picks one cipher suite and sends its own random number.
- Certificate — the server presents its certificate (and intermediates) so the client can verify identity and obtain its public key.
- Key exchange — both sides contribute material to derive a shared pre-master secret (modern suites use Diffie-Hellman; see the next level).
- Finished — each side sends an encrypted, hashed summary of the whole handshake. If they match, the handshake wasn't tampered with and encrypted data can flow.
A cipher suite names the algorithms in play, e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: ECDHE for key exchange, RSA for the certificate signature, AES-256-GCM for bulk encryption, SHA-384 for the hash.
Advanced
TLS 1.3 (2018) is a major cleanup. It's faster and safer by removing footguns:
- One round trip (1-RTT). The client guesses the key-exchange parameters in its ClientHello, so encrypted data flows after a single round trip instead of two.
- RSA key exchange removed. Only (EC)DHE ephemeral key exchange remains, which means forward secrecy is mandatory.
- Legacy ciphers gone. RC4, 3DES, static RSA, MD5, SHA-1, CBC-mode and renegotiation are all out.
- Encrypted handshake. Most of the handshake after ServerHello is encrypted, leaking far less metadata.
With ephemeral Diffie-Hellman, each session uses a throwaway key pair. Even if the server's long-term private key is stolen later, past recorded sessions cannot be decrypted. Without it, one stolen key unlocks years of captured traffic.
Validating the chain. A server rarely presents a certificate signed directly by a root CA. Instead there's a chain: your server's leaf cert → one or more intermediate CA certs → a root in the trust store. The client verifies each signature up the chain, checks the name matches (via SAN), checks validity dates, and checks revocation.
| Extension | Purpose |
|---|---|
| SNI | Server Name Indication — the client states which hostname it wants in the ClientHello, so one IP can serve many TLS sites (virtual hosting). |
| ALPN | Negotiates the application protocol during the handshake — this is how HTTP/2 and HTTP/3 are selected. |
| Session resumption | Tickets / PSK let a returning client skip most of the handshake, including TLS 1.3's 0-RTT early data (with replay caveats). |
Deep dive
Normally only the server presents a certificate. With mTLS the server also requests a client certificate, so both ends authenticate cryptographically — no passwords. It's the backbone of zero-trust service-to-service auth (and service meshes like Istio) where every workload carries its own short-lived cert.
TLS authentication is only as strong as the PKI (Public Key Infrastructure) behind it. The whole edifice rests on the trust store of root CAs and on CAs only issuing certs to verified owners. Mis-issuance is serious — which is why Certificate Transparency logs now publicly record every cert, so rogue ones get spotted. For the maths underneath certificates and key exchange, see public-key cryptography.
Revocation handles compromised certificates before they expire:
- CRL — Certificate Revocation Lists: large lists of revoked serials. Clunky.
- OCSP — an online yes/no check per cert. OCSP stapling lets the server attach a fresh signed proof so the client needn't query the CA (faster, more private).
The failures you'll actually hit:
| Error | Cause |
|---|---|
NET::ERR_CERT_DATE_INVALID | Expired certificate (or a wrong client clock). Automate renewal. |
...COMMON_NAME_INVALID / name mismatch | The hostname isn't in the cert's SAN list. |
unable to get local issuer certificate | Server didn't send the intermediate cert — incomplete chain. |
| Handshake failure / no shared cipher | Client and server have no cipher suite in common (often old client vs hardened server). |
| Mixed content warnings | An HTTPS page loading sub-resources over plain HTTP. |
A short history of TLS getting attacked. Each of these drove a cleanup that TLS 1.3 finished:
| Name | What it broke | Lesson |
|---|---|---|
| Heartbleed (2014) | An OpenSSL bug leaked server memory — including private keys. | Implementation bugs, not just protocol design, leak keys. Patch fast; rotate after. |
| POODLE / BEAST | Exploited SSL 3.0 / old CBC cipher modes. | Disable SSL 3.0 and legacy CBC suites. |
| Downgrade attacks | Tricked peers into negotiating weaker crypto. | TLS 1.3 authenticates the whole handshake; drop old versions entirely. |
| Weak RSA key exchange | No forward secrecy → recorded traffic decryptable later. | Require ECDHE; TLS 1.3 removed static RSA. |
Even in TLS 1.3 the SNI (the hostname you're visiting) is sent in the clear, so eavesdroppers still learn which site you want. Encrypted Client Hello (ECH) encrypts that first message against a key published in DNS, hiding the destination on shared hosting/CDNs. It's the current frontier of handshake privacy.
openssl s_client is the universal TLS debugger — it shows the negotiated version, the full chain, and any verification error:
# Full handshake details: chain, cipher, TLS version, verify result
openssl s_client -connect shellquest.io:443 -servername shellquest.io
# Just the certificate's validity dates
echo | openssl s_client -connect shellquest.io:443 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer
# Force TLS 1.3 and show negotiated protocol
openssl s_client -connect shellquest.io:443 -tls1_3 -alpn h2TLS uses slow asymmetric crypto briefly — to authenticate the server via a certificate chain and to agree (with ephemeral Diffie-Hellman) on a shared secret — then switches to fast symmetric encryption for the data. TLS 1.3 makes this one round trip with mandatory forward secrecy. The padlock is only as trustworthy as the CA system and a correctly configured, unexpired, full-chain certificate.
Frequently asked questions
What is the difference between SSL and TLS?
TLS is the modern successor to SSL. All SSL versions (1.0–3.0) are broken and deprecated; what people call 'SSL' today is almost always TLS. Use TLS 1.2 or 1.3.
Why does TLS use both symmetric and asymmetric encryption?
Asymmetric crypto is ideal for authentication and securely agreeing on a key but is computationally expensive. Symmetric crypto is fast but needs a shared key. TLS uses asymmetric crypto during the handshake to establish a symmetric session key, then uses that for the bulk data.
What is forward secrecy?
A property where each session uses ephemeral key-exchange keys, so compromising the server's long-term private key later cannot decrypt previously recorded sessions. TLS 1.3 makes it mandatory by removing static RSA key exchange.
What does the padlock icon actually guarantee?
That the connection is encrypted and the server presented a valid certificate chaining to a trusted CA for that hostname. It does not guarantee the site is safe or honest — only that you're talking privately to whoever controls that domain.
Why am I getting 'unable to get local issuer certificate'?
The server isn't sending the intermediate CA certificate(s), so the client can't build a complete chain to a trusted root. Fix it by configuring the server to serve the full chain (leaf + intermediates).
ShellQuest turns concepts like this into bite-sized lessons, puzzles and labs you actually practise.
Join the waitlist