Chapter 2 — Networks and internet services
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes"]
N1["2.1 How a request travels"]
N2["2.2 What a certificate proves"]
N3["2.3 Common failures"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 How a request travels"]
N2["2.2 What a certificate proves"]
N3["2.3 Common failures"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX004"]
[Learning outcomes]
|
v
[2.1 How a request travels]
|
v
[2.2 What a certificate proves]
|
v
[2.3 Common failures]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes
You will (1) explain DNS, HTTP and TLS in a city web service; (2) describe what TLS certificates prove; (3) recognise common network-level failures.
2.1 How a request travels
When a citizen types permits.harbourview.example, the browser asks DNS for the server's address, opens a TCP connection and starts a TLS handshake before sending any HTTP request. Rosa learns the order matters: DNS answers are not protected by TLS, so an attacker who poisons DNS could direct the browser elsewhere, but TLS certificate checks would then fail because the attacker cannot present a valid certificate for the council's name. This is why certificate validation is the anchor of web security: it detects redirection that lower layers cannot stop. She practises tracing these steps in a lab with test domains.
2.2 What a certificate proves
A TLS certificate binds the name permits.harbourview.example to a public key, signed by a certificate authority the browser trusts. RFC 5280 defines the fields, including subject alternative names and validity dates. The certificate proves that whoever completes the handshake holds the private key for that name; it does not prove the site is safe or that the council's code is bug-free. Rosa explains this to the council's communications team, who had told citizens that "the padlock means your data is safe", and suggests more accurate wording about the connection being private.
2.3 Common failures
Rosa lists network failures she will meet: expired certificates, certificates missing a needed name, incomplete chains where the server does not send the intermediate certificate, clocks set wrong on clients and old clients that cannot negotiate modern TLS versions defined in RFC 8446. Each produces a different browser error. She builds a one-page guide mapping error messages to likely causes for the service desk, so that first-line staff can collect the right details before escalating. The guide later reduces time spent diagnosing simple certificate problems.
Worked example
Rosa traces DNS, TCP and TLS for the permit site, corrects the "padlock means safe" wording and writes an error-to-cause guide for the service desk.
Synthetic case. Domains and teams are invented; RFC 5280 and RFC 8446 are real.
Errors and limits
TLS does not protect DNS lookups by itself. A valid certificate says nothing about application security.
Exercises
- EX004 — DNS and TLS. Why does certificate validation still protect a citizen if DNS is poisoned? Rubric: 3 = attacker cannot present a valid certificate for the council's name;; 2 = valid cert;; 1 = it doesn't;; 0 = none.
- EX005 — Padlock wording. What did Rosa suggest instead of "the padlock means your data is safe"? Rubric: 3 = wording that the connection is private, not that the site or data is safe;; 2 = accurate;; 1 = unchanged;; 0 = none.
- EX006 — Incomplete chain. What is an incomplete chain failure? Rubric: 3 = the server does not send the intermediate certificate;; 2 = missing intermediate;; 1 = expired;; 0 = none.
Synthesis
Web security rests on certificate validation over layers that are otherwise unprotected; knowing failure patterns speeds diagnosis.
Continue studying — chapter 02 of 30
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →