Computer Networks

Network Security

The Threat Model

The internet's core protocols were designed in

JrCodex·7 min read

Jr Codex Computer Networks Notes

Level: Intermediate Prerequisites: Module 5, Chapter 5: Email and Other Protocols Time to complete: ~15 minutes


Table of Contents

  1. The Assumption That Failed
  2. What an Attacker Can Do
  3. The Five Security Goals
  4. Attacks by Layer
  5. Thinking in Threat Models
  6. Summary & Next Steps

1. The Assumption That Failed

The Original Design Context
─────────────────────────────────────────
  The internet's core protocols were designed in
  the 1970s and 80s among a few dozen research
  institutions who knew each other.

  The design goal was SURVIVABILITY — keep working
  when links fail. Not SECURITY.

  So the defaults are:
    ARP    believes any reply (Module 2, Chapter 4)
    BGP    believes any advertisement (Module 3,
           Chapter 4)
    DNS    unauthenticated and unencrypted
           (Module 5, Chapter 1)
    SMTP   anyone may claim any From: address
           (Module 5, Chapter 5)
    HTTP   plaintext
    TCP    accepts any segment with plausible
           sequence numbers
─────────────────────────────────────────
The Pattern
─────────────────────────────────────────
  Every one of these is the same failure: a
  protocol designed among trusted parties, later
  exposed to everyone.

  Security has been RETROFITTED — DNSSEC, RPKI,
  SPF/DKIM/DMARC, TLS — which is why it is
  optional, partially deployed, and easy to
  misconfigure.

  Understanding this explains why network security
  looks like a collection of patches rather than a
  coherent design. It is.
─────────────────────────────────────────

2. What an Attacker Can Do

Positions
─────────────────────────────────────────
  OFF-PATH
    Can send packets, cannot see yours.
    Must GUESS sequence numbers, ports, tokens.
    ── the weakest position, and the most common

  ON-PATH (passive)
    Can OBSERVE traffic. Shared wifi, a
    compromised router, an ISP, a network tap.

  ON-PATH (active)
    Can observe, MODIFY, DROP and INJECT.
    ── the machine-in-the-middle. The strongest
       network position.

  ENDPOINT COMPROMISE
    Owns one of the machines. No network protocol
    helps you here — which is why "TLS protects
    everything" is wrong.
─────────────────────────────────────────
The Capabilities
─────────────────────────────────────────
  EAVESDROP    read data in transit
  MODIFY       alter it undetected
  IMPERSONATE  claim to be someone else
  REPLAY       resend a captured valid message
  DENY SERVICE make a resource unavailable
  ANALYSE      learn from METADATA alone — who
               talks to whom, when, how much

  Note that the last one survives encryption. TLS
  hides WHAT you said, not THAT you said it to
  that host.
─────────────────────────────────────────

3. The Five Security Goals

What We Want, and What Provides It
─────────────────────────────────────────
  CONFIDENTIALITY   only the intended recipient can
                    read it
                    ──► ENCRYPTION (Chapter 2)

  INTEGRITY         tampering is DETECTED
                    ──► MACs and signatures
                    ── note: not prevented,
                       detected

  AUTHENTICATION    the other party is who they
                    claim
                    ──► certificates, signatures
                        (Chapter 3)

  NON-REPUDIATION   the sender cannot later deny
                    sending it
                    ──► digital signatures

  AVAILABILITY      the service stays reachable
                    ──► capacity, filtering,
                        redundancy (Chapter 4)
─────────────────────────────────────────
THE DISTINCTION PEOPLE MISS
─────────────────────────────────────────
  CONFIDENTIALITY WITHOUT AUTHENTICATION IS
  WORTHLESS.

  An encrypted connection to an attacker is
  perfectly private — between you and the attacker.

  This is exactly what a machine-in-the-middle
  achieves, and it is why certificate validation
  (Chapter 3) matters more than the cipher suite.

  Disabling certificate verification "to make it
  work" removes the property that makes encryption
  meaningful, while leaving the reassuring padlock
  in place.
─────────────────────────────────────────
Integrity Is Detection, Not Prevention
─────────────────────────────────────────
  Nothing stops an on-path attacker from flipping
  bits. Cryptographic integrity means the receiver
  NOTICES and rejects the message.

  Which is sufficient: a modification you detect
  and discard has failed.

  It also means an active attacker can always DENY
  SERVICE — they can corrupt everything and you
  will correctly reject all of it. Availability is
  a separate goal for a reason.
─────────────────────────────────────────

4. Attacks by Layer

LAYER 2 — the local link
─────────────────────────────────────────
  ARP SPOOFING       claim to be the gateway;
                     intercept the LAN
                     (Module 2, Chapter 4)
  MAC FLOODING       overflow a switch's table so
                     it floods like a hub
  ROGUE DHCP         hand out your own gateway and
                     DNS addresses
  EVIL TWIN          a fake access point with a
                     familiar name

  DEFENCES: dynamic ARP inspection, DHCP snooping,
  port security, 802.1X — and TLS above, so
  interception yields nothing readable.
LAYER 3 — routing and addressing
─────────────────────────────────────────
  IP SPOOFING        forge a source address.
                     Enables reflection attacks and
                     defeats IP-based access
                     control.
  BGP HIJACKING      advertise someone else's
                     prefixes (Module 3, Chapter 4)
  ICMP ABUSE         redirects, floods

  DEFENCES: ingress filtering (BCP 38) at network
  edges, RPKI for BGP, and never trusting a source
  IP as authentication.
LAYER 4 — the transport
─────────────────────────────────────────
  SYN FLOOD          exhaust connection state
                     (Module 4, Chapter 3)
  TCP RESET          inject an RST to kill a
                     connection
  SESSION HIJACKING  guess or steal sequence
                     numbers

  DEFENCES: SYN cookies, randomised initial
  sequence numbers, and encryption which makes
  injection detectable.
LAYER 7 — the application
─────────────────────────────────────────
  DNS SPOOFING / CACHE POISONING
  PHISHING           the human is the target
  INJECTION          SQL, command, template
  CREDENTIAL STUFFING
  APPLICATION DDOS   expensive requests, in volume

  DEFENCES: DNSSEC, input validation,
  parameterised queries (DBMS Notes, Module 3,
  Chapter 6), rate limiting, MFA.
─────────────────────────────────────────
The Observation Worth Making
─────────────────────────────────────────
  Layers 2-4 attacks are largely NEUTRALISED by
  encryption and authentication above them.

  An attacker who fully controls your local network
  can still not read a properly validated TLS
  session.

  Which is why the modern posture is: assume the
  NETWORK IS HOSTILE, and secure the CONNECTION
  rather than the network. That is Chapter 4's zero
  trust, stated early.
─────────────────────────────────────────

5. Thinking in Threat Models

The Four Questions
─────────────────────────────────────────
  1. WHAT ARE YOU PROTECTING?
     Credentials? Personal data? Availability?
     Money? Different assets, different defences.

  2. FROM WHOM?
     An opportunistic scanner, a competitor, an
     insider, a state actor. Their capability and
     motivation differ enormously.

  3. WHAT CAN THEY DO?
     Section 2's positions. On-path or off-path
     changes everything.

  4. WHAT IS THE COST OF FAILURE, AND OF DEFENCE?
     Security is a trade. Perfect security is
     unavailable and unusable.
─────────────────────────────────────────
Why This Matters More Than a Checklist
─────────────────────────────────────────
  "Is this secure?" has no answer. "Is this secure
  AGAINST THIS ATTACKER, protecting THIS asset?"
  does.

  A café's guest wifi and a hospital's clinical
  network face different adversaries and protect
  different things. A control that is essential in
  one is theatre in the other.
─────────────────────────────────────────
Three Principles Worth Carrying
─────────────────────────────────────────
  DEFENCE IN DEPTH
    Assume any single control fails. Encryption AND
    authentication AND authorisation AND
    monitoring.

  LEAST PRIVILEGE
    Grant the minimum access needed. This limits
    what a compromise reaches, not whether one
    happens.

  FAIL SECURELY
    When something breaks, deny rather than allow.
    An authentication service that is down should
    reject, not admit everyone.

  All three assume compromise WILL happen. That
  assumption is the difference between security
  engineering and hoping.
─────────────────────────────────────────

6. Summary & Next Steps

Key Takeaways

  • The internet's core protocols were designed among mutually trusting institutions, so every one of them authenticates nothing by default and security has been retrofitted.
  • An attacker's position — off-path, on-path passive, on-path active, or endpoint — determines their capability far more than any single vulnerability.
  • Confidentiality without authentication is worthless: an encrypted channel to an attacker is exactly what a machine-in-the-middle provides.
  • Cryptographic integrity detects tampering rather than preventing it, which is sufficient for correctness and is why availability is a separate goal.

Concept Check

  1. Why do ARP, BGP, DNS and SMTP all share the same fundamental weakness?
  2. Why is disabling TLS certificate verification worse than it appears, given the connection is still encrypted?
  3. Why does encryption at layer 6 neutralise most layer 2 and 3 attacks?

Next Chapter

Chapter 2: Cryptography for Networks


Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Computer Networks Index