The ideas behind TLS as a role-play — a certificate authority vouches for a name, the server proves it holds the key, the browser checks both, and an impostor tries four ways to pass for the server. Keys, stamps and documents instead of bytes, and why only the server has to prove who it is.
TLS protects a password on its way to a server, and that raises one question: how does a browser know
it is talking to shop.example, and not to someone standing in its place?
- Only the server has to answer it, because the browser is the one about to hand over a secret.
- Six parties play out the answer: a root CA, an intermediate CA, the server, the browser, an
eavesdropper (Eve) and an impostor (Mallory).
- The next page,
TLS in Action, shows the same handshake record by
record, and every step here links to the matching step there.
Reading the drawing
- Four objects are documents, each a card with its type on its title: the certificate, the
certificate request (CSR), the challenge and the token file.
- Messages and checks live for one connection or one step, so they are plain text under a label.
- An object lies in the card of the party that holds it. When it changes hands, it flies along an
arrow to its place:
- sent, it leaves the sender and lands at the receiver;
- copied, it stays with the sender and appears at the receiver too;
- used up, it fades where it lay.
- The browser's certificates form a tree: the root certificate in its trust store at the top, the
intermediate's under it, the server's under that, each link marked with the result of its check.
- Keys have one colour per key pair: a solid key is the private half, an outline key the public
half. A stamp takes the colour of the private key that made it.
- Mallory's four attempts are the last four scenes; the buttons on her card jump to the start of
each.
The keys: private halves for stamping, public halves for checking
Each party that has to be recognised makes a key pair, keeps the private half, and hands out the public
half.
- A stamp (a digital signature) can be made only with a private key, and checked by anyone with the
matching public key.
- The root certificate is in the browser's trust store before the story starts: the browser's maker
put it there.
- It holds the root's public key, and is stamped by the root itself.
- So it is trusted because of where it is kept, and every trust decision the browser makes goes back
to the trust store.
- The root's private key is kept offline. It signs only the certificate of an intermediate CA, which
holds a second key pair and signs the servers' certificates day to day.
- The server's private key never leaves the server. Everything the server proves, it proves by
stamping with it.
The certificate: a CA's word for a name
A certificate is a document a CA writes and stamps, saying "this public key belongs to shop.example".
- The server writes a certificate request: its name and its public key, with no stamp, and sends it
to the CA.
- The CA checks that the sender controls the name, as Let's Encrypt does:
- it sends a challenge holding a token;
- the server publishes the token as a file at
http://shop.example/.well-known/acme-challenge/…; - the CA fetches it from its own network.
- The intermediate writes the certificate: the same name and key, itself as the issuer, the dates,
and its own stamp. The request is used up.
- The server keeps the certificate, with a copy of the intermediate's, and shows both to every
visitor.
- The stamp covers every word, so a changed name breaks it.
- A certificate holds no secret: the server shows it to every visitor.
The browser trusts the root, has never seen the intermediate, and receives both of the server's
certificates in the handshake. It builds the chain from them and checks each link:
- The root's public key, from the trust store, checks the stamp on the intermediate's certificate.
- The intermediate's public key, from that certificate, checks the stamp on the server's.
A root key that signs a few intermediates a year can stay offline. If an intermediate's key is stolen,
the root withdraws that one certificate, and every browser's trust store stays as it is.
The browser's checks: who is on the other end
When the browser connects, it first agrees a shared session key with whoever answered, then checks who
that is.
- The key agreement is Diffie-Hellman:
- each side makes a fresh key pair and sends the public half;
- each combines its own private half with the other's public half;
- both get the same shared session key, and Eve, with only the two public halves, gets nothing.
- The chain checks out link by link up to the root in the trust store: the CA vouches that the
server's public key belongs to
shop.example. - The name on the certificate is the one the browser asked for.
- A stamp on this conversation, made with the server's private key, checks out with the public key in
the certificate.
- It covers both key shares, so it was made now, for this connection.
- So the party the browser shares its session key with holds the server's private key.
Who proves what: the server's name, the client's password
TLS proves the server to the client; the password proves the client to the server.
- The browser has the secret to protect. It is about to send a password, so the one thing it must get
right is who receives it.
- The server learns who the client is afterwards, from the password or the cookie sent inside the
encrypted connection, as on the
Basic HTTP Authentication and
Cookies and Sessions pages. TLS makes those safe to send.
- Mutual TLS is the case where the client has a certificate too, for machines talking to machines.
Mallory's four attempts
Each attempt fails at one check.
- In each one Mallory does agree a shared session key with the browser: the connection is encrypted, to
her.
- Encryption alone would hand her the password; the checks stop it.
| Attempt | What she has | Where it fails |
|---|
| Sign her own certificate | a certificate stamped with her own key | no chain leads from it to the trust store |
| Ask the CA for one | a request for shop.example with her key | the CA finds no token on the real shop.example |
| Copy the real certificate | the genuine certificate, which is public | she cannot stamp the conversation with the server's private key |
| Edit a real certificate | her own certificate for mallory.example, renamed | the intermediate's stamp no longer matches the words |
The course
Authentication and Secrets covers the same ground in
its chapters TLS and The chain of trust.