Lesson 12 — TLS

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 3 — the key exchange (the seal), certificates and CAs (identity), the handshake that fuses them Builds on: Lesson 10 (the TCP handshake this runs on top of), Lesson 11 (the two padlock promises, certificates, SSL, man-in-the-middle)

Table of contents

1. Layer anchor and the name
2. The impossible-sounding problem
3. The paint analogy — agreeing a secret in the open
4. Why the eavesdropper is stuck
5. Promise 1 solved — but a gap remains
6. Proving who you agreed the key with
7. Couldn’t the middle just copy the certificate?
8. The handshake, step by step
9. The whole thing, one glance
10. Tying up the Cloudflare asterisk
11. Easy to get wrong
12. Old way vs improved understanding
13. Terms locked in
14. Deliberately not covered yet
15. Sources

Layer anchor and the name

TLS sits just below Layer 7 (the text). It wraps the HTTP text in its seal after TCP (Layer 4) has built its connection. The order on every HTTPS visit:

1. TCP three-way handshake   → a connection exists (numbers and receipts)
2. TLS handshake             → a seal and a verified identity are established
3. sealed HTTP flows         → GET, headers, body, response — all scrambled

TLS = Transport Layer Security. A protocol (agreed script) that secures things at roughly the transport level. Old name: SSL, from Lesson 11 — “SSL certificate” and “TLS certificate” are the same object.

The impossible-sounding problem

To scramble a message so only the other side can unscramble it, both sides need to share a secret — a value used to lock and unlock. Agree on a secret, and everything after is easy: scramble with it, send noise, unscramble with it.

So the whole game reduces to one step: the browser and the server must agree on a shared secret.

Now the problem, stated slowly. They have never met — this is a first-ever visit. And the only way to send anything is across the network: the exact network full of hops that can read everything, the postcard problem from Lesson 11.

How do two strangers agree on a secret, while shouting across a room where everyone hears every word?

Whatever the browser sends to propose a secret, every hop sees it too. It sounds impossible — if the eavesdropper hears every word, how can two people end up knowing something the eavesdropper does not?

The paint analogy — agreeing a secret in the open

This is not a loose metaphor; it maps precisely onto the real math.

Each side has one secret color it never tells anyone. There is also a public color everyone — including the eavesdropper — can see. Say the public color is yellow.

public (everyone sees):   yellow
browser's secret:         red    (told to no one)
server's secret:          blue   (told to no one)

The exchange, entirely in the open:

Step 1. The browser mixes its secret red into the public yellow → orange. It sends the orange. The eavesdropper sees orange fly past.

Step 2. The server mixes its secret blue into the public yellow → green. It sends the green. The eavesdropper sees green fly past.

browser sends:   orange   (yellow + red)     ← eavesdropper sees orange
server sends:    green    (yellow + blue)    ← eavesdropper sees green

Step 3 — the magic. The browser takes the green and mixes in its secret red. The server takes the orange and mixes in its secret blue.

browser:  green + red    =  yellow + blue + red
server:   orange + blue  =  yellow + red + blue

Both arrive at the same mixture — yellow+red+blue. A shared secret, agreed without ever being sent.

Why the eavesdropper is stuck

The eavesdropper has: yellow (public), orange, and green. To reach the shared color they would need to un-mix orange back into pure red, or green back into pure blue — to extract a secret color out of a blend.

Mixing paint is easy; un-mixing it is effectively impossible.

Colors combine in a second, but no one can look at orange and pull the exact red back out. The whole scheme rests on an action trivial one way and hopeless in reverse.

Real TLS replaces paint with numbers that have this same one-way property — easy to combine, effectively impossible to pull apart, even with the world’s computers. The colors are exactly the shape of it: a public value everyone has, a private value each side keeps, blends exchanged in the open, both sides arriving at a shared secret the watcher cannot reconstruct.

This exchange is called the key exchange, and the shared secret is the key — the thing that locks and unlocks the scramble. (Surfshark’s tunnel doing a “Curve25519 key exchange,” from the VPN discussion, is this same idea with specific numbers.)

Promise 1 solved — but a gap remains

Two strangers now share a key no eavesdropper can derive, and all the HTTP text gets scrambled with it. The seal is real — promise 1 from the padlock panel, solved.

But the key exchange guarantees only that the browser shares a secret with whoever it did the exchange with. It says nothing about who that partner was.

Picture the airport. The browser starts the paint exchange meaning to reach GitHub. Someone sits in the middle — the man-in-the-middle from Lesson 11. They do the paint dance with the browser (pretending to be GitHub), and separately do another paint dance with the real GitHub (pretending to be the browser):

browser  ⟷  [middle]  ⟷  real GitHub
        key A            key B

Two perfect seals, both unbreakable — and the middle sits between them, unsealing with key A, reading, resealing with key B. Encryption worked flawlessly and protected nothing, because the key was agreed with the wrong party.

When the paint exchange finishes, how do you know your partner was really github.com and not an impostor?

Proving who you agreed the key with

You cannot verify GitHub yourself — you have never met it. But someone you already trust may have.

Your browser ships with a built-in list of a few dozen trusted organizations, called Certificate Authorities (CAs), installed by the vendor before you ever opened it. You trust them by default, transitively: you trust Apple/Google/Mozilla to have chosen honest CAs.

The certificate from Lesson 11 — the server’s “identity document” — is precisely a file saying “the holder is really github.com,” signed by one of those CAs. GitHub obtained it by proving to a CA, ahead of time, that it controls github.com (Let’s Encrypt automating exactly this check).

During the handshake, the server hands the browser this certificate. The browser checks: is this signed by a CA on my trusted list, and does the name match? If yes — the partner is vouched-for. If no — the browser refuses, producing the red “your connection is not private” screen. That screen means promise 2 failed.

Couldn’t the middle just copy the certificate?

The certificate is sent in the open and is not secret — so the middle can copy it. Why can’t the impostor present GitHub’s certificate as its own?

Because a signature here is not a picture that can be photocopied. It is a special number, produced from content combined with a secret that only the CA has — checkable by anyone using the CA’s public half (built into the browser), but producible only by the holder of the secret half. The same one-way shape as the paint: easy to verify, effectively impossible to forge.

And the certificate the CA signed says, in effect, “the real github.com holds a particular private secret.” During the handshake, the server must prove it holds that secret — not by sending it (that would expose it), but by using it in a way only the true holder could. The impostor has the public certificate but not GitHub’s private secret. It can wave the certificate around all it likes — the moment it must prove ownership, it cannot. The forgery collapses exactly where it must.

The two promises, now both mechanical:

promise 1 (seal)      key exchange — a shared key no eavesdropper can derive
promise 2 (identity)  a CA-signed certificate the server proves it truly owns

Together they defeat the man-in-the-middle completely: it cannot read (no key) and cannot impersonate (no provable certificate).

The handshake, step by step

This runs after TCP’s three-way handshake has finished — a connection already exists.

Step 1 — Browser says hello, and proposes its paint

Browser → GitHub:
   "Hello. Here's the public color context I want to use,
    and here is my blend (yellow + my private red = orange)."

The orange goes out in the open. The browser’s private red never leaves the machine.

Step 2 — GitHub replies with three things at once

GitHub → Browser:
   (a) "Here's my blend (yellow + my private blue = green)."   ← paint half
   (b) "Here's my certificate."                                ← identity document
   (c) "Here's proof I own the certificate's private secret."  ← the anti-impostor step

(a) the green — both sides now have what they need: the browser has GitHub’s green, GitHub has the browser’s orange. Each mixes in its own private color and independently reaches the same key, yellow+red+blue. The seal is agreed. (Promise 1.)

(b) the certificate — the CA-signed file. The browser checks the signature against its trusted CA list and checks the name. If genuine, the document is accepted.

(c) the proof of ownership — GitHub takes the paint messages that just flew by — this conversation’s orange and green — and signs them with its private secret. The browser verifies that signature using the public half inside the certificate.

Step 3 — why the impostor dies exactly here

real GitHub:  has the private secret → can sign THIS conversation's paint → check passes
the impostor: copied the certificate, but NOT the private secret
              → cannot sign this conversation's paint → check fails → browser refuses

The signature must be over this handshake’s specific paint values, freshly. A photocopied old signature will not match, and a new one cannot be produced without the secret. The forgery collapses at the one step that requires proving ownership rather than showing a document. (Promise 2.)

Step 4 — browser confirms, sealed traffic begins

Browser → GitHub:  "Checks passed. Switching to sealed mode."

From this instant everything — GET / HTTP/1.1, the Host header, a password in a POST body, the response — is scrambled with the shared key. The postcard became a sealed box.

The whole thing, one glance

   (TCP three-way handshake already done — connection exists)

1. Browser → GitHub:  hello + orange (my paint blend)
2. GitHub → Browser:  green (my paint blend)
                    + certificate (CA-signed "I am github.com")
                    + signature over THIS handshake's paint (proof I own it)
3. Browser checks:   • both sides now compute the same key   → seal ready
                     • certificate signed by a trusted CA?   → identity ready
                     • signature valid for this conversation? → impostor ruled out
4. Browser → GitHub:  confirmed, switch to sealed
5. → all HTTP text now flows scrambled ←

Two load-bearing insights:

The private secrets never move. The browser’s red stays with the browser; GitHub’s blue and its certificate-secret stay with GitHub. Only blends and proofs cross the wire. Nothing that must stay secret is ever sent — which is the whole reason this survives a network full of watchers.

Identity is bound to this conversation, not asserted in general. GitHub does not merely claim “I’m GitHub” — it proves it by signing the exact paint values of the handshake happening right now. That freshness is what stops a recorded, replayed, or copied credential from working.

(Real TLS 1.3 compresses this into fewer messages and adds key-refresh machinery so a single stolen key cannot unlock past recordings — but the shape above is exactly right, and it is the shape every engineer carries.)

Tying up the Cloudflare asterisk

Lesson 11 deferred a question: if Cloudflare stands at the door with the certificate, what protects the leg from Cloudflare onward to the real server?

Now it frames exactly. That is a second, separate TLS relationship. Visitor↔Cloudflare is one sealed-and-verified hop; Cloudflare↔origin is another (or, misconfigured, is not sealed at all). It is not one seal end to end — it is two seals with Cloudflare knowingly in the middle. That is the honest limit, and it is a real setting chosen at deploy time.

Easy to get wrong

The seal and the identity are two different problems. The key exchange stops reading; the certificate stops impersonation. Encryption without verified identity is a seal with an unknown partner — possibly the attacker.

The private secrets are never transmitted. A common wrong mental model is “the browser sends GitHub the key.” It does not. Both sides derive the same key from blends. Nothing secret crosses the wire.

A certificate proves a name, not honesty. It attests “the holder controls this name,” nothing more. A malicious site can hold a perfectly valid certificate for its own malicious name. The padlock means “sealed with the name in the bar,” not “this site is trustworthy.”

Copying a certificate is useless without its private secret. Certificates are public. Security rests on the un-sendable private secret the server must prove it holds, freshly, each handshake.

The red warning screen is promise 2 failing, not a seal failing. “Your connection is not private” usually means the certificate is missing, expired, self-signed, or for the wrong name — an identity failure, not an encryption failure.

Cloudflare (or any front door) is a deliberate middle. End-to-end is really two seals. Whether the second leg is secured is a configuration choice, not an automatic guarantee.

Old way vs improved understanding

Terms locked in

• TLS (Transport Layer Security) — the protocol that seals and verifies HTTPS; SSL is its old name
• key exchange — the paint-style procedure that agrees a shared secret over an open network
• key — the shared secret used to scramble and unscramble
• one-way property — easy to combine, effectively impossible to reverse; the basis of both the seal and the signature
• certificate — a CA-signed file asserting a name is held by the presenter
• Certificate Authority (CA) — a trusted signer whose public halves ship in browsers
• signature — a number producible only with a private secret, verifiable by anyone with the public half
• proof of ownership — the server signing this handshake’s values, proving it holds the certificate’s private secret
• TLS handshake — the sequence that establishes seal and identity, run right after the TCP handshake

Deliberately not covered yet

• The exact mathematics (Diffie-Hellman, elliptic curves, RSA) — the paint captures the shape; the numbers are beyond this track’s scope
• The chain of trust (intermediate CAs, root CAs) — real certificates are signed in a short chain, not directly by a root; introduced only if a deployment needs it
• Certificate revocation — how a compromised certificate is cancelled before it expires; deferred
• mTLS (mutual TLS) — where the client also presents a certificate; appears naturally in Kubernetes service-to-service security, Part 4
• The Cloudflare-to-origin leg settings — a real deploy-time choice; revisited in the AWS/proxy parts

Sources

Source note: the paint-mixing story is the standard teaching analogy for Diffie-Hellman key exchange, and it is faithful to the real structure — a public base, private exponents kept secret, and a shared result derived independently by both sides. The 1976 paper is where the idea entered the open world.

End of Lesson 12. Next: firewalls — deliberate blocking, and the long-promised answer to why low ports are protected.