Chapter 2 — Networks and protocols

Chapter 2 — Networks and protocols

Lesson map

Lesson 02 published. Map, example, EX005.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 How messages arrive"]
  N2["2.2 Why fakes work"]
  N3["2.3 Configuring warnings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX005"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 How messages arrive"]
  N2["2.2 Why fakes work"]
  N3["2.3 Configuring warnings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX005"]

[Learning outcomes]
    |
    v
[2.1 How messages arrive]
    |
    v
[2.2 Why fakes work]
    |
    v
[2.3 Configuring warnings]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX005]

Learning outcomes

You will (1) explain how emails and texts reach staff; (2) describe why sender details can be faked; (3) configure simple warnings.

2.1 How messages arrive

Emails reach Kestrel through its cloud mail service, which passes them through a filter before delivering them. Texts reach drivers' phones through mobile networks. Priya learns that the sender shown on an email or text is easy to fake, because the basic protocols were designed to deliver messages, not to prove who sent them. Email authentication checks can detect some forgeries of Kestrel's own domain, but they cannot stop attackers who register similar-looking domains or send texts using a company name as the sender label.

2.2 Why fakes work

Priya studies a synthetic example: an email from a domain that differs from Kestrel's by one letter, asking office staff to update a customer's delivery address and to send an invoice copy. It passes authentication because the attacker owns that lookalike domain. Staff under time pressure read the familiar name and act. Whitten and Tygar (1999) showed that security tools leave users confused when the interface does not guide them, and Priya sees that staff need clear cues rather than technical knowledge.

2.3 Configuring warnings

With the IT lead, Priya configures an external tag on emails from outside Kestrel and a warning when a sender's display name matches a staff member but the address is external. She tests both with synthetic messages in a test mailbox before enabling them. She also drafts a short message for drivers stating that route changes always come through the route app, never by text. Each cue gives staff a simple signal at the moment of decision without requiring them to understand protocols.

Worked example

Priya explains message delivery and forgery, analyses a lookalike domain example and configures external tags, name warnings and a driver message.

Synthetic case. Examples are synthetic; Whitten and Tygar (1999) is real.

Errors and limits

Tags lose effect if overused. Drivers may not read messages.

Exercises

• EX005 — Lookalike pass. Why does the lookalike email pass authentication? Rubric: 3 = the attacker owns the lookalike domain;; 2 = ownership;; 1 = vague;; 0 = none.
• EX006 — Whitten and Tygar. What did Whitten and Tygar (1999) show? Rubric: 3 = unguided security interfaces confuse users;; 2 = usability;; 1 = vague;; 0 = none.
• EX007 — Testing warnings. Where were the warnings tested first? Rubric: 3 = a test mailbox with synthetic messages;; 2 = test mailbox;; 1 = live inboxes;; 0 = none.
• EX008 — Driver rule. What rule did Priya draft for drivers? Rubric: 3 = route changes only come through the route app;; 2 = app only;; 1 = vague;; 0 = none.

Synthesis

Protocol limits leave staff to judge messages, so simple cues must guide them.

Continue studying — chapter 02 of 18

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →