Educatifu
Open menu

TLS — how the padlock works

Every https:// page runs on TLS, which combines the Foundations primitives — key exchange, certificates and symmetric encryption — into a secure channel. Here's the whole handshake.

CoreCyber Security~14 min

Before this lesson

  • Lesson: Keys, and how strangers share a secret

Everything the Foundations track built — hashing, keys, the Diffie–Hellman exchange — comes together in one protocol you use thousands of times a day: TLS (Transport Layer Security), the "S" in HTTPS. When your browser shows a padlock, TLS is what put it there.

What TLS guarantees

A raw internet connection is like shouting across a crowded room — anyone can listen, and anyone can pretend to be the person you're talking to. TLS wraps that connection to provide three things at once:

  • Confidentiality — the data is encrypted, so eavesdroppers see only noise.
  • Integrity — tampering is detected, so nobody can quietly alter what's sent.
  • Authentication — you're really talking to yourbank.com, not an impostor.

The first two you already understand (encryption and hashing/MACs). The third — authentication — is the part that makes TLS more than "just encryption", and it is where most of the cleverness lives.

The handshake

Before any real data flows, client and server run a handshake (see the diagram):

  1. ClientHello — the browser says hello and lists the cipher suites it supports, plus some random data.
  2. ServerHello + certificate — the server replies and sends its certificate, which contains its public key and its identity (yourbank.com).
  3. Key agreement — using the certificate's key and a Diffie–Hellman-style exchange (the widget below is exactly this step), both sides derive the same session key without ever sending it.
  4. Encrypted data — from here on, everything is encrypted with fast symmetric crypto using that session key. Asymmetric crypto set up the key; symmetric crypto carries the traffic — the best of both, as the keys lesson foreshadowed.

Try the key-exchange widget below to see step 3 in miniature: two parties agreeing on a shared secret over a channel an eavesdropper can read.

Certificates and trust

Here is the subtle part. Anyone can generate a key pair and claim to be yourbank.com. What stops them? A certificate is that claim signed by a Certificate Authority (CA) — an organisation your browser already trusts. The browser checks the signature against its built-in list of CAs; if the certificate for yourbank.com isn't validly signed by a trusted CA, you get the scary warning page. This chain of trust — you trust the CA, the CA vouches for the site — is what turns encryption into authenticated encryption, and it's the backbone of trust on the web.

With a secure channel established, the next question is who's on the other end of it — proving you are who you say you are. That's authentication, next.

Client and server exchange hello messages and a certificate, agree a shared key, then send encrypted data.
A simplified TLS handshake — authenticate, agree a key, then encrypt.

Try it: sharing a secret in the open

Public, known to everyone: p = 23, g = 5

Alice

sends A = g6 mod p = 8
computes B6 mod p = 2

Bob

sends B = g15 mod p = 19
computes A15 mod p = 2

Public channel (an eavesdropper sees all of this)

p = 23, g = 5, A = 8, B = 19

Shared secret: 2 — both derived the same key, but it was never sent.

Alice and Bob agree on a shared secret (2) without ever transmitting it. An eavesdropper knows p, g, A and B — yet to recover the secret they must find a private exponent from gx mod p, the discrete logarithm problem, which is easy here (p = 23) but astronomically hard for the huge primes used in practice. That gap is what keeps HTTPS safe.

Key takeaways

  • TLS gives confidentiality, integrity and authentication for internet traffic — it is what the browser padlock means.
  • It uses asymmetric crypto + a certificate to authenticate the server and agree a key, then fast symmetric crypto for the data.
  • Certificates, signed by trusted Certificate Authorities, are what stop an attacker from impersonating a site.

Sources

  1. [1]Transport Layer Security — Wikipediaen.wikipedia.org
  2. [2]RFC 8446 — The TLS 1.3 protocoldatatracker.ietf.org
  3. [3]How does HTTPS work? — Cloudflare Learningcloudflare.com

← All Cyber Security lessons

Bring us the problem, not a perfect specification

Tell us what needs to change, who it affects and any important deadline. We will review the context and reply with useful next questions.

  1. 01Share contextDescribe the workflow, constraint or risk.
  2. 02Clarify togetherWe identify missing facts and useful options.
  3. 03Choose a startAgree a focused assessment or delivery step.
Start a conversation