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. The simulator plays out the answer with
six parties: a root CA, an intermediate CA, the server, the browser, an eavesdropper and an impostor. The
reader plays each role in turn. The next page,
TLS in Action
, shows
the same handshake record by record, and every step here links to the matching step there.
The simulator's layout
- Six cards, one per party, each of one fixed size. The two CAs are on top, the root at the left and
the intermediate beside it; the browser is below them on the left and the server on the right, with Eve and Mallory between them, lower still, and the list of
events under them. A card whose contents outgrow it scrolls.
- 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. What lives for one connection or one
step is plain text under a label: the messages (the hellos, the signature, the HTTP request and
response, the encrypted records Eve copies) and the checks. An object lies in the card of the party
that holds it. When it changes hands it appears at its source, waits there a moment, and flies along
an arrow to its place, which is outlined until it lands:
- sent, it leaves the sender and lands at the receiver, as the certificate request does on its way
to the CA;
- copied, it stays with the sender and appears at the receiver too, as the CA's certificate does
when it ships in the browser;
- used up, it fades where it lay, as the request does once the CA has written the certificate.
- The objects the current step touched are open; the rest fold to their title, and a click on the
title opens or folds one.
- The browser's certificates form a tree. The root certificate in its trust store is at the top, the
intermediate's certificate hangs under it, and the server's under that, each link marked with the
result of its check; a certificate with no chain to the store sits apart.
- The lit button is on the card whose turn it is; pressing it plays that role's step.
Step above the stage does the same, and Prev undoes a step.
- The events card is where the story is read. It keeps every step so far, with the current step's
explanation open; a click on any step opens or folds its own, and the button inside goes back to that
step.
- Keys have one colour per key pair: a solid key is the private half, an outline key the public half.
A stamp is drawn in the colour of the private key that made it.
- Mallory's four attempts are the last four scenes, played one after the other; Step runs through
all of them. The buttons on her card jump to the start of each.
The keys: private halves stamp, public halves check
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 CA's 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. 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: the CA vouches for a name
A certificate is a document a CA writes and stamps, saying "this public key belongs to shop.example".
It starts with a document the server writes:
- The server writes a certificate request: its name and its public key, with no stamp, and sends it
to the CA.
- The intermediate writes a new document, the certificate, with 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 certificate, and shows both to every visitor.
The CA stamps only after checking that the sender controls the name. It sends a challenge holding a
token, the server publishes the token as a file at http://shop.example/.well-known/acme-challenge/…,
and the CA fetches it from its own network: that is how Let's Encrypt checks a name.
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 no browser's trust store has to change.
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, and
each combines its own private half with the other's public half. Both get the same shared session key; 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. The party the
browser shares its session key with therefore holds the server's private key.
Only the server proves who it is
TLS proves the server to the client; the password proves the client to the server. The browser never holds
a certificate, and the server never asks for one:
- 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, and 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 |
Simplifications in the simulator
- The certificate request carries no stamp. A real one is signed with the server's own private key, which
proves the sender holds it; the simulator leaves that out, so that a stamp on a document always means
its issuer vouched for it.
- One intermediate stands between the root and the server; real chains have one or two, and the
browser may fetch a missing one itself.
- Mallory takes over the café Wi-Fi without it being shown how; the CA's check reaches the real site
because it runs from the CA's own network.
The course
Authentication and Secrets
covers the same ground in
its chapters TLS and The chain of trust.