HTTPS — TLS handshake, certificates, CA: Exercises

Definition Three acronyms we reuse below (defined once, here)

AEAD = Authenticated Encryption with Associated Data. A cipher mode (like AES-GCM) that does two jobs in one pass: it encrypts the data and produces a short tag — a fingerprint that lets the receiver detect any tampering. The "associated data" part is extra header info that isn't encrypted but is covered by the tag.
SNI = Server Name Indication. A small field in the first TLS message that says which hostname the client wants (e.g. bank.com). One IP can host many sites, so the server needs SNI to know which certificate to present.
PRF = Pseudo-Random Function. A one-way "blender": you feed it a secret plus some public inputs, and it churns out key-material bytes that look random. Same inputs → same output on both sides, but you cannot run it backwards to recover the secret. TLS uses it to turn a shared secret into session keys.

Prerequisite links you may want open: Symmetric vs Asymmetric Encryption, Diffie–Hellman Key Exchange, Digital Signatures & Hashing, Public Key Infrastructure (PKI), TCP — three-way handshake, HTTP — methods, status codes, DNS.

Level 1 — Recognition

(Can you point at the right idea when you see it?)

L1.1

HTTPS runs on which port by default, and what two things is it made of?

Recall Solution

HTTPS = HTTP + TLS, on port 443. Plain HTTP uses port 80; TLS is the encrypted, authenticated tunnel that HTTP bytes ride inside.

L1.2

Match each TLS guarantee to what it stops: (a) Confidentiality (b) Integrity (c) Authentication

A café router silently rewrites the page.
Someone on the Wi-Fi reads your password.
A fake server pretends to be bank.com.

Recall Solution

(a) Confidentiality → 2 (reading is stopped; eavesdropper sees only ciphertext).
(b) Integrity → 1 (tampering is detected via the MAC or the AEAD tag — the tamper-detection fingerprint defined at the top of this page).
(c) Authentication → 3 (the certificate proves identity).

L1.3

In the mnemonic "Cool Servers Carry Keys, Change, Finish", name the six handshake messages in order.

Recall Solution

ClientHello → ServerHello → Certificate → Key exchange → ChangeCipherSpec → Finished.

Level 2 — Application

(Apply one rule to a concrete case.)

L2.1

A server offers cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Split it into its four jobs.

Recall Solution

ECDHE — the key exchange (ephemeral Diffie–Hellman → gives forward secrecy).
RSA — the authentication (the certificate is signed / verified with RSA).
AES_128_GCM — the bulk symmetric cipher (fast, encrypts the actual data; GCM is an AEAD mode, so it also produces the integrity tag).
SHA256 — the hash used inside the PRF and MAC. Notice: two different keys are involved — RSA/ECDHE only bootstraps, AES does the heavy lifting. This is the hybrid design.

L2.2

Diffie–Hellman with tiny numbers. Public prime $p = 23$ , generator $g = 5$ . Alice's secret $a = 6$ , Bob's secret $b = 15$ . Here $g^{a} mod p$ means "raise $g$ to the power $a$ , then take the remainder after dividing by $p$ " — a clock that wraps around at $p$ . Compute the public values $A, B$ and the shared secret $s$ .

Recall Solution

$A = g^{a} mod p = 5^{6} mod 23 = 15625 mod 23 = 8$ .
$B = g^{b} mod p = 5^{15} mod 23 = 19$ .
Alice computes $s = B^{a} mod p = 1 9^{6} mod 23 = 2$ .
Bob computes $s = A^{b} mod p = 8^{15} mod 23 = 2$ . Both get $s = 2$ without ever sending it — that is the DH magic.

Read the figure below to see why they land on the same $s$ . Follow the two lavender/mint boxes at the top: those are the secrets $a$ and $b$ , which never leave their owner. Each secret goes down into a public half ( $A = 8$ , $B = 19$ ) that is safe to send — the coral arrows across the middle show exactly what an eavesdropper is allowed to see. Now trace the two diagonal arrows into the yellow box: Alice raises the received $B$ to her secret ( $B^{a}$ ), Bob raises the received $A$ to his secret ( $A^{b}$ ). Because $g^{ab} = g^{ba}$ , both diagonals land in the same yellow box, $s = 2$ . The picture makes the crossing structure obvious: the secrets stayed home, yet both computed one common value.

Figure — HTTPS — TLS handshake, certificates, CA

L2.3

Your browser trust store contains root R. A site sends: leaf shop.com (signed by intermediate I), and I (signed by R). Write the two signature checks the browser performs, in order.

Recall Solution

Verify shop.com's signature using I's public key (from the intermediate cert). ✔ → I vouches for shop.com.
Verify I's signature using R's public key (from the trust store). ✔ → R vouches for I, and R is already trusted. Trust is transitive up the chain: leaf → intermediate → root. The root itself is trusted because it was pre-installed, not because anyone signed it.

Level 3 — Analysis

(Reason about why a step exists or what breaks without it.)

L3.1

In the TLS 1.2 handshake, the client encrypts the pre-master secret with the server's public key. Explain precisely how this single act simultaneously (a) delivers a secret and (b) authenticates the server.

Recall Solution

(a) Delivers a secret: only whoever holds the matching private key can decrypt the pre-master secret. So the secret arrives safely — no eavesdropper can read it.
(b) Authenticates: because the connection only continues if the server successfully decrypts and both sides derive the same keys, the server proves it holds the private key that matches the public key in the certificate. An imposter without that private key can't decrypt → the Finished MAC won't match → handshake fails. One message, two jobs. (Note: TLS 1.3 replaces this RSA-transport step with ECDHE + a signature, precisely to get forward secrecy.)

L3.2

Why does the Finished message contain a MAC computed over the entire handshake transcript, including the earlier cleartext messages?

Recall Solution

The early messages (ClientHello, ServerHello, cipher list) travel before encryption is on, so a MITM could tamper with them — e.g. strip strong cipher suites to force a weak one (a "downgrade attack"). The Finished MAC is a fingerprint of everything said so far, keyed by the freshly derived session key. If any earlier byte was altered, the two sides' transcripts differ → their MACs differ → the handshake aborts. This protects the negotiation itself, not just the later data.

L3.3

A recorded TLS session used RSA key transport (no ephemeral DH). A year later the server's long-term private key leaks. What can an attacker who saved the old ciphertext now do — and why would ECDHE have prevented it?

Recall Solution

With RSA transport, the pre-master secret was encrypted with the server's long-term public key. The leaked private key decrypts it → attacker derives the old session keys → decrypts the whole saved session retroactively.
With ECDHE, each session used a throwaway DH key pair. The DH secrets $a, b$ were never stored and never derivable from the long-term key. Leaking the long-term key reveals nothing about past sessions. This property is forward secrecy, and it's why TLS 1.3 keeps only ECDHE/DHE suites.

Level 4 — Synthesis

(Combine several ideas into one trace or design.)

L4.1

Write the full life of a request to https://bank.com/login, from typing the URL to encrypted data flowing. List the ordered stages and the one job of each.

Recall Solution

DNS lookup — resolve bank.com → IP address.
TCP — three-way handshake — SYN, SYN-ACK, ACK to port 443 → reliable byte pipe.
ClientHello — TLS version, random $r_{c}$ , cipher list, SNI = bank.com (the Server Name Indication field defined at the top — it tells the server which certificate to present).
ServerHello — chosen cipher suite, random $r_{s}$ .
Certificate — server's cert chain (leaf + intermediates).
Client verifies cert — chain to trusted root, domain matches SNI, not expired/revoked.
Key exchange — pre-master secret sent (RSA-encrypted) or DH shares exchanged (ECDHE).
Derive keys — both sides run the PRF (the one-way key "blender" defined at the top) over the pre-master secret plus $r_{c}$ and $r_{s}$ → identical session keys, computed locally and never sent.
ChangeCipherSpec + Finished — switch on encryption; Finished MAC proves the transcript was untampered.
Encrypted HTTP — now the real GET /login (an HTTP request) flows inside the tunnel.

L4.2

Design question: a startup wants "encryption, so we made a self-signed certificate." A security reviewer rejects it. Give the precise failure and the exact attack it enables.

Recall Solution

Failure: a self-signed cert has no chain to a trusted root. The browser can't verify that this public key really belongs to the claimed domain — anyone can self-sign a cert for any name.
Attack enabled (MITM): an attacker sits in the middle, presents their own self-signed cert for startup.com, and the client has no way to tell it apart from the "legit" self-signed one. The attacker terminates TLS, reads/alters everything, and re-encrypts to the real server.
Lesson: encryption without authentication is hollow — you'd have a secure channel to possibly the attacker. Use a CA-signed cert (e.g. Let's Encrypt) so the chain of trust holds.

L4.3

Repeat the DH computation of L2.2 but change only Bob's secret to $b = 3$ (keep $p = 23$ , $g = 5$ , $a = 6$ ). Recompute $B$ and the shared secret $s$ , and confirm both sides still agree.

Recall Solution

$B = 5^{3} mod 23 = 125 mod 23 = 10$ .
Alice: $s = B^{a} mod p = 1 0^{6} mod 23 = 6$ .
Bob: $s = A^{b} mod p = 8^{3} mod 23 = 512 mod 23 = 6$ . Both get $s = 6$ . Changing one secret changes the whole shared key — exactly why every session (with fresh ephemeral secrets) gets a fresh key.

Level 5 — Mastery

(Subtle cases, degenerate inputs, and "why exactly.")

L5.1

evil-phishing.com obtains a perfectly valid Let's Encrypt certificate and a green padlock. Is the padlock lying? Explain what a cert does and does not prove.

Recall Solution

The padlock is not lying. A certificate proves exactly one thing: you are securely talking to the real owner of the domain in the address bar — here, evil-phishing.com. It says nothing about whether that owner is honest, safe, or who you think they are. Authenticity ≠ honesty. Anyone who controls a domain can get a valid cert for it. The correct defence is checking the domain name itself, not just the padlock.

L5.2

Two extreme DH cases. With $p = 23$ , $g = 5$ : (a) Alice foolishly picks $a = 0$ . What is her public $A$ , and what shared secret does an attacker instantly know? (b) Suppose a bad generator gave $A = 1$ . What does the attacker learn about $s$ ?

Recall Solution

(a) $A = g^{0} mod 23 = 1$ . Then $s = B^{a} = B^{0} = 1$ for any Bob. The attacker sees $A = 1$ and immediately knows the "secret" is $1$ — zero security. This is why implementations forbid tiny/degenerate exponents.
(b) If $A = 1$ , then $s = A^{b} = 1^{b} = 1$ regardless of Bob's secret. Again the shared secret collapses to $1$ . Lesson: the security rests on $a$ (and $b$ ) being large, random, and secret. Degenerate inputs like $0$ or values producing $1$ destroy the discrete-log hardness the whole scheme depends on.

L5.3

Order these by when their protection kicks in during the handshake, and state what would still be exposed if the connection died right after each: (i) ServerHello, (ii) Certificate verified, (iii) Finished exchanged.

Recall Solution

After (i) ServerHello: nothing is protected yet. Both randoms and the cipher choice are in cleartext; no identity confirmed, no keys agreed. Everything is exposed.
After (ii) Certificate verified: the client now knows who the server claims to be, but keys aren't finalised and encryption isn't on. Still no confidential data has flowed — nothing sensitive exposed because none was sent.
After (iii) Finished exchanged: encryption is on and the transcript is proven untampered. Only now is it safe to send the GET /login. If the connection died before any HTTP was sent, no application data leaked. Key insight: TLS deliberately sends zero sensitive application data until after Finished. The ordering guarantees you never leak before all three goals (authenticate, agree keys, verify transcript) are met.

Recall One-line self-test before you leave

Cover the answers: What layer order gets you to encrypted HTTP? ::: DNS → TCP → TLS → HTTP. What does a valid certificate prove — and not prove? ::: Proves you talk to the real domain owner; does not prove they're honest/safe. Why does ECDHE give forward secrecy? ::: Throwaway per-session keys mean a later long-term key leak can't decrypt recorded past traffic.