Chapter 7 — Networks and protocols
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["7.1 The TLS 1.3 handshake"]
N2["7.2 Certificate validation"]
N3["7.3 Protocol risks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 The TLS 1.3 handshake"]
N2["7.2 Certificate validation"]
N3["7.3 Protocol risks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX019"]
[Learning outcomes]
|
v
[7.1 The TLS 1.3 handshake]
|
v
[7.2 Certificate validation]
|
v
[7.3 Protocol risks]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) explain the TLS 1.3 handshake at a high level; (2) describe certificate validation by browsers; (3) identify protocol-level risks such as downgrade and misconfiguration.
7.1 The TLS 1.3 handshake
When a patron opens Tidewell's portal, the browser and server run a TLS 1.3 handshake from RFC 8446. The client sends supported algorithms and a key share; the server replies with its key share, and both derive keys using HKDF from RFC 5869. The server sends its certificate and signs the handshake transcript to prove it holds the private key, then both confirm the handshake with message authentication codes. All later data is encrypted with an authenticated cipher such as AES-GCM. Priya captures the handshake in a lab using a test server and identifies each message.
7.2 Certificate validation
The browser checks that the server's certificate chains to a root it trusts, that the name matches portal.tidewell.example, that it is within its validity dates and that it has not been revoked. RFC 5280 defines the certificate fields and path validation. If any check fails, the browser shows a warning. Priya explains to library staff why clicking through such warnings is dangerous: the warning may be the only sign that someone on the café Wi-Fi is intercepting the connection with a forged certificate.
7.3 Protocol risks
Older TLS versions allowed attackers to push connections down to weaker algorithms. TLS 1.3 removes legacy options and protects against downgrade by signing the whole handshake. Most practical problems now come from configuration: servers still offering TLS 1.0, expired certificates or applications that disable verification. Priya scans Tidewell's public services with permission and finds the staff wiki still accepts TLS 1.0. She reports it to Grace, who schedules a configuration change, and she records the scan's scope and authorisation in her notes. She retests after the change.
Worked example
Priya identifies each TLS 1.3 handshake message, explains certificate checks to staff, and reports a TLS 1.0 setting found in an authorised scan.
Synthetic case. Tidewell's hosts are invented; RFC 8446, RFC 5869 and RFC 5280 are real.
Errors and limits
Scanning systems without permission is unethical and may be illegal. A valid certificate shows who runs a server, not that the server is safe.
Exercises
- EX019 — Transcript signature. Why does the server sign the handshake transcript? Rubric: 3 = to prove it holds the certificate's private key and protect against tampering/downgrade;; 2 = prove key;; 1 = encrypt;; 0 = none.
- EX020 — Browser checks. List three checks the browser makes on a certificate. Rubric: 3 = three of chain to trusted root, name match, validity dates, revocation;; 2 = two;; 1 = one;; 0 = none.
- EX021 — Scan finding. What did Priya's authorised scan find? Rubric: 3 = staff wiki accepting TLS 1.0;; 2 = old TLS;; 1 = vague;; 0 = none.
Synthesis
TLS 1.3 secures connections when certificates validate and configurations stay current; most failures are now operational.
Continue studying — chapter 07 of 40
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →