Chapter 12: Network Security¶

Summary¶

This chapter introduces network security primitives in transit — cryptography fundamentals, symmetric and public-key encryption, hash functions, digital signatures, certificate authorities, X.509 certificates, TLS (handshake, cipher suites), IPsec and VPNs, firewalls (stateful), intrusion detection and prevention, common attacks (spoofing, MITM, DDoS, replay, SYN flood, ARP spoofing), defense in depth, and zero-trust architectures. Students leave able to assess the security posture of a small deployment.

Concepts Covered¶

This chapter covers the following 24 concepts from the learning graph:

Cryptography Basics
Symmetric Encryption
Public Key Cryptography
Hash Function
Digital Signature
Certificate Authority
X509 Certificate
TLS Protocol
TLS Handshake
Cipher Suite
IPsec
VPN
Firewall
Stateful Firewall
Intrusion Detection
Intrusion Prevention
Spoofing Attack
Man In The Middle
DDoS Attack
Replay Attack
SYN Flood
ARP Spoofing
Defense In Depth
Zero Trust Network

Prerequisites¶

This chapter builds on concepts from:

Sealing the comb

Buzz the bee waving welcome Welcome back. A hive guards its entrance — only foragers with the right pheromone signature pass. Inside, every brood cell is sealed before it matters. Networks need the same instincts: authenticate who is talking, encrypt what they say, defend against attackers who can see your packets. Let's trace the route! This chapter is about every safeguard the previous chapters quietly assumed.

12.1 What Network Security Provides¶

Up to this point we have treated the network as a delivery service: packets get from A to B, and bytes arrive in order. Network security asks a sharper question: who is A really, who is B really, can anyone in between read or change the bytes, and what happens when the network is under attack? Three classical security goals shape the answer.

Confidentiality — only the intended recipient can read the data. Achieved with encryption.
Integrity — the recipient can detect any modification of the data in flight. Achieved with cryptographic hashes and message authentication codes.
Authentication — both parties can verify each other's identity. Achieved with public-key cryptography and certificates.

Two more goals appear in modern thinking. Availability — the service stays usable under attack. Non-repudiation — neither party can later deny what they sent. The first three are the essential triad; everything else builds on them.

This chapter develops the cryptographic primitives that make these guarantees possible, then the protocols (TLS, IPsec) that compose them into end-to-end protection, then the operational defenses (firewalls, IDS/IPS) that protect networks at their boundaries, and finally the most common attacks the field has had to cope with.

12.2 Cryptography Basics¶

Modern network security rests on a small set of cryptographic primitives. Knowing what each does, and what guarantee it provides, is the foundation of every higher-level protocol.

A symmetric encryption algorithm takes a message and a secret key, and produces ciphertext that can only be decrypted by someone with the same key. Symmetric ciphers (AES, ChaCha20) are fast — gigabytes per second on commodity hardware — and provide confidentiality. The catch is that both parties must already share the secret key; getting that shared key in the first place is a separate problem.

A public-key cryptography algorithm uses a pair of mathematically-related keys: a public key (which anyone can know) and a private key (kept secret by the owner). Anyone can encrypt to the public key, and only the holder of the private key can decrypt. Equivalently, the holder can sign with the private key, and anyone can verify with the public key. Public-key algorithms (RSA, Diffie-Hellman, elliptic-curve variants) are slow — kilobytes per second — but they solve the key-distribution problem. Modern protocols use public-key cryptography only to establish shared secrets, then switch to symmetric crypto for bulk data.

A hash function takes any input and produces a fixed-size output (typically 256 or 512 bits) that is irreversible (you cannot derive the input from the output) and collision-resistant (it is computationally infeasible to find two inputs that hash to the same output). The standard modern hash functions are SHA-256 and SHA-3. Hashes are how integrity is checked: send a message and its hash, recompute on receipt, and any change to the message produces a wildly different hash.

A digital signature combines public-key crypto and hashing. The sender hashes the message and encrypts the hash with their private key — that ciphertext is the signature. Anyone with the sender's public key can decrypt the signature, recompute the hash from the message, and verify the two match. A successful verification proves both that the message has not been changed and that someone in possession of the matching private key produced it.

Primitive	Purpose	Typical algorithms
Symmetric encryption	Confidentiality (fast)	AES-GCM, ChaCha20-Poly1305
Public-key encryption / key exchange	Establishing shared secrets	RSA, ECDHE, Curve25519
Hash function	Integrity, fingerprinting	SHA-256, SHA-3, BLAKE2
Digital signature	Authenticity + integrity	RSA-PSS, ECDSA, Ed25519

12.3 Certificate Authorities and X.509 Certificates¶

Public-key cryptography lets you verify that a message was signed by the holder of a particular private key. It does not, by itself, tell you whose key that is. If the attacker can substitute their own public key for the legitimate one, they can sign their own messages and you have no way to know.

The standard solution is a public-key infrastructure (PKI) anchored by certificate authorities (CAs). A CA is a trusted third party whose public key is preinstalled in every browser and operating system. When a website operator wants to be able to authenticate, they generate a key pair and ask the CA to sign a statement of the form "the public key for example.com is <key>." The signed statement is an X.509 certificate — a standardized document containing the subject's name, the public key, the issuing CA, validity dates, and the CA's digital signature.

When a client connects to a server, the server presents its X.509 certificate. The client verifies the chain: the server's cert is signed by an intermediate CA whose cert is signed by a root CA whose key is preinstalled. If every signature in the chain checks out, and every cert is within its validity period, and the certificate's subject name matches the hostname the client typed, then the client trusts that the server is who it claims to be. This sequence — chain of trust, validity check, name match — is the workhorse of the modern web.

Several browser ecosystems publish the list of root CAs they trust (Mozilla's CA list, Google's Chrome Root Store, Apple's Trusted Root Program). Inclusion is governed by audits and policy. Let's Encrypt, founded in 2014, automated the certificate-issuance process and made TLS certificates free and ubiquitous; before Let's Encrypt, most small websites were not encrypted because certs were inconvenient and expensive. Today, more than 95% of public web traffic flows over TLS, and the certificate infrastructure underneath is one of the modern Internet's most successful systems.

12.4 TLS and the TLS Handshake¶

The dominant transport-layer security protocol is TLS (Transport Layer Security), defined for the current generation in RFC 8446 (TLS 1.3). TLS sits between TCP and the application — when you see "HTTPS" you are seeing HTTP over TLS over TCP. TLS does three things: authenticates the server (and optionally the client), establishes a fresh shared session key, and provides confidentiality and integrity for the data that follows.

The TLS handshake is the negotiation phase. In TLS 1.3 it requires only one round trip:

ClientHello. The client sends a list of supported cipher suites, a list of supported TLS versions, a random number (client_random), and a Diffie-Hellman key share for key exchange.
ServerHello. The server replies with the chosen cipher suite, a random number (server_random), its own DH key share, the server's X.509 certificate, and a signed handshake transcript (which authenticates the server). At this point both sides can derive the shared secret using their two DH key shares.
Application data. The client immediately begins sending application data encrypted with keys derived from the shared secret. The server can also send application data after its first message.

A cipher suite is a bundle of cryptographic algorithm choices used together: the key-exchange algorithm (typically ECDHE — Elliptic Curve Diffie-Hellman Ephemeral, providing forward secrecy), the bulk encryption algorithm (typically AES-GCM or ChaCha20-Poly1305, providing both confidentiality and integrity), and the hash function used in the key derivation (typically SHA-256 or SHA-384). TLS 1.3 reduced the number of valid cipher suites dramatically — only a few combinations remain — eliminating many of the foot-guns from earlier versions.

TLS 1.3 also supports 0-RTT resumption: a returning client can use a session ticket from a previous connection to send application data immediately, with no handshake round trip at all. 0-RTT data has weaker security properties (it's vulnerable to replay), so it must be used carefully — typically for idempotent operations like initial GET requests.

TLS version	Year	Handshake RTTs	Notable changes
TLS 1.0	1999	2	Original IETF version (deprecated)
TLS 1.1	2006	2	Defenses against CBC attacks (deprecated)
TLS 1.2	2008	2	AES-GCM, SHA-256 (still common)
TLS 1.3	2018	1 (or 0 on resumption)	Simplified suites, mandatory forward secrecy

Diagram: TLS 1.3 Handshake Walkthrough¶

Animated TLS 1.3 handshake showing key exchange, certificate validation, and session-key derivation

Type: microsim sim-id: tls-handshake-walkthrough
Library: p5.js
Status: Specified

Build an interactive MicroSim that animates the TLS 1.3 handshake step by step, showing each message and the keys derived at each stage.

Canvas: 940 px wide by 640 px tall, responsive down to 360 px. A 120 px control panel sits below.

Layout:

Two vertical timelines: Client (left) and Server (right). Time flows top to bottom.
Each TLS message is drawn as an arrow with a labeled box showing the message type and key contents (e.g., "ClientHello: supported_versions, cipher_suites, key_share, client_random").
A "key derivation" panel between the timelines updates as each step completes, showing which keys are now derived (early secret, handshake secret, master secret).

Animation phases:

ClientHello sent.
ServerHello + Certificate + signed transcript sent. Highlight: client now verifies cert chain against preinstalled CAs.
Both sides compute DH shared secret. Highlight: forward secrecy because the DH key shares are ephemeral.
Client and server derive matching session keys via HKDF.
Application data flows, encrypted.

Controls panel:

Buttons: Step / Play / Reset.
Toggle: "Show TLS 1.2 (compare)" splits the canvas to also show the older 2-RTT handshake.
Toggle: "0-RTT mode" replays the handshake using a session ticket; data flows immediately on the first message.
Toggle: "Compromised CA" injects a malicious cert and shows the verification failure.

Visual style:

Client messages in honey amber.
Server messages in slate.
Encrypted messages drawn with a small lock icon.
Key-derivation panel with each derived key fading in as it becomes available.

Learning objectives:

(Bloom — Understanding) Students explain each step of the TLS 1.3 handshake.
(Bloom — Analyzing) Students compare TLS 1.3 with TLS 1.2 in round trips and security guarantees.
(Bloom — Evaluating) Students judge when 0-RTT is appropriate and what its limitations are.

Implement in pure p5.js with the existing MicroSim CSS theme.

12.5 IPsec and VPNs¶

TLS protects a single transport-layer connection. IPsec, defined across RFCs 4301 et al., protects entire networks at the IP layer. IPsec is the foundation of most enterprise virtual private networks (VPNs).

IPsec has two main protocols. AH (Authentication Header) provides integrity and authentication but no confidentiality. ESP (Encapsulating Security Payload) provides integrity, authentication, and (optionally) confidentiality; ESP is the protocol almost everyone actually uses. Both can run in two modes: transport mode encapsulates only the transport-layer payload, leaving the original IP header intact; tunnel mode encapsulates the entire original packet inside a new IP packet, hiding the inner addresses from any observer between the IPsec endpoints.

A VPN (Virtual Private Network) is the operational concept: an encrypted tunnel that makes a remote network appear local. Two large categories exist:

Site-to-site VPN. Two organizations' networks are connected by IPsec gateways at each end; traffic between them is encrypted as it traverses the public Internet. Branch offices are typically connected to headquarters this way.
Remote-access VPN. Individual users connect from anywhere (laptops, phones) into the corporate network through a VPN gateway. Implementations include IPsec, OpenVPN, WireGuard, and SSL/TLS-based VPNs.

WireGuard, which appeared in 2018 and was upstreamed into Linux in 2020, is a modern alternative to IPsec with a much smaller code base (under 4000 lines) and a focused design. It has rapidly become the default for personal and many business VPNs. The newer protocol does not replace IPsec for site-to-site interoperability with legacy equipment but is increasingly common everywhere else.

12.6 Firewalls and Stateful Inspection¶

A firewall is a network device that examines traffic crossing a boundary and applies a policy — usually allowing or denying based on rules. Firewalls have evolved through three generations:

Packet filters (1980s–early 90s) examine each packet independently against rules based on source/destination IP, port, and protocol. Simple, fast, but easily bypassed by traffic that fits the surface pattern.
Stateful firewalls track active connections. A stateful firewall remembers that a client opened an outbound TCP connection to a server, and automatically permits the matching inbound traffic for that connection while blocking unsolicited inbound. The connection table holds state for every active flow. Stateful firewalls are the industry baseline today.
Application-layer firewalls (also called next-generation firewalls or deep-packet-inspection firewalls) parse application-layer protocols and apply policy based on what the traffic actually does. A next-generation firewall might allow HTTP traffic but block specific HTTP requests that look like SQL injection attempts.

A stateful firewall's key property is that it understands the bidirectional nature of TCP and UDP "conversations." A typical rule might be: "Allow outbound traffic to port 443 from any internal host. Allow the matching inbound traffic for established connections." The firewall does not need an explicit inbound rule for the reply — its connection-tracking state knows that this packet belongs to an active outbound connection and lets it through.

Firewalls live at network boundaries: the edge of an organization (between LAN and Internet), between zones within a datacenter (between web tier and database tier), and on every host (the host firewall, run by the operating system). Defense in depth (Section 12.10) layers these firewalls so an attacker who breaches one still faces others.

12.7 Intrusion Detection and Prevention¶

Firewalls block what is obviously not allowed. Some attacks look like ordinary traffic until you study their behavior over time. Intrusion detection systems (IDS) and intrusion prevention systems (IPS) address this gap.

An IDS observes traffic, compares it to known attack patterns or learned baselines of normal behavior, and generates alerts when something looks suspicious. An IDS is passive — it watches but does not block. The two main categories: signature-based IDS (matches known patterns, like antivirus does for files) and anomaly-based IDS (uses statistics or machine learning to flag deviations from a baseline). Snort and Suricata are the most widely-deployed open-source IDS engines.

An IPS is an IDS with the ability to act — typically inline in the network path, dropping or modifying suspicious traffic in real time. IPS adds latency and risks blocking legitimate traffic if its detection is too aggressive, which is why some organizations run IDS-only deployments and rely on humans to act on alerts.

Both systems have practical limitations. Signature-based detection misses novel attacks. Anomaly-based detection generates false positives that drown operators in alerts. Encrypted traffic is opaque to most IDS/IPS — they can see flow metadata (sizes, timings, IPs) but not content, which has shifted some detection upstream into TLS-decrypting middleboxes (with their own controversies) or into endpoint agents.

12.8 Common Attacks¶

A handful of attack categories shape every defensive design.

Spoofing attacks forge the source address (or other identifying field) of a packet, frame, or message. IP spoofing fakes the source IP to impersonate another host. MAC spoofing fakes the source MAC to impersonate another link-layer neighbor. Email spoofing forges the From address. The defense varies by layer: ingress filtering at ISPs (RFC 2827, BCP 38) drops outbound packets with non-local source IPs; ARP inspection on managed switches drops MAC-spoofing attempts; SPF, DKIM, and DMARC defend email.

A man-in-the-middle (MITM) attack interposes the attacker between two parties who think they are talking to each other directly. The attacker observes (and may modify) every message. Without authentication, MITM is undetectable. With authentication (TLS certificates, SSH host keys) the attacker has to trick the victim into accepting a fake credential; Public Key Pinning, Certificate Transparency, and HSTS are layered defenses.

A DDoS (Distributed Denial of Service) attack floods a victim with so much traffic that legitimate requests cannot get through. DDoS comes in two main flavors: volumetric (raw bandwidth, often hundreds of gigabits per second from a botnet) and application-layer (well-formed but extremely numerous requests, exhausting application resources). Defenses include traffic scrubbing services (Cloudflare, AWS Shield), upstream filtering, and rate-limiting policies. The largest publicly-disclosed DDoS attacks now exceed 10 Tbps in volumetric size.

A replay attack captures a legitimate message and replays it later to achieve some effect. Without freshness protection (sequence numbers, timestamps, nonces), a captured authentication can be replayed by an attacker. Defense: include a nonce or sequence number in every authenticated message, and reject duplicates.

A SYN flood attack sends many TCP SYN segments without completing the handshake, filling the server's half-open-connection table and refusing service to legitimate clients. The classic defense is SYN cookies: the server encodes the connection state into the SYN+ACK's sequence number itself, so it doesn't need to remember anything until the client's ACK arrives. SYN cookies cost a small amount of CPU but defeat the attack.

ARP spoofing (also called ARP poisoning) fakes ARP replies on a LAN to redirect traffic. An attacker can convince a host that the attacker has the IP of the gateway, and the host then sends every off-LAN packet to the attacker, who can read it, modify it, and forward it on. ARP has no built-in authentication; defenses are at the switch (Dynamic ARP Inspection, DHCP snooping) or at the network layer (HTTPS, IPsec) so that even if traffic is redirected, the attacker cannot read it.

Attack	Targets	Common defense
IP spoofing	Source authenticity	Ingress filtering (BCP 38)
MITM	Authentication	TLS, SSH, certificate validation
DDoS	Availability	Traffic scrubbing, upstream filtering
Replay	Message freshness	Nonces, timestamps
SYN flood	Server connection table	SYN cookies
ARP spoofing	LAN delivery	Dynamic ARP Inspection, encrypted upper layer

Diagram: Anatomy of a Man-in-the-Middle Attack¶

Animated comparison of an unprotected connection and a TLS-protected connection under MITM

Type: microsim sim-id: mitm-and-tls-defense
Library: p5.js
Status: Specified

Build an interactive MicroSim that animates a man-in-the-middle attack on an unprotected connection, then on a TLS-protected connection, demonstrating how authentication blocks the attack.

Canvas: 960 px wide by 600 px tall, responsive down to 360 px. A 120 px control panel sits below.

Layout:

Three nodes arranged horizontally: Client (left), Attacker (middle), Server (right).
A "Real path" toggle: client believes traffic goes direct to server, but actually traverses the attacker.

Animation phases:

Phase 1 — Plaintext. Client sends "Send $1000 to Alice" in cleartext. Attacker reads it, modifies to "Send $10000 to Mallory", and forwards. Server processes the modified message. Attack succeeds.
Phase 2 — TLS without verification (incorrect). Client connects via TLS but skips certificate verification. Attacker presents its own fake certificate, completes its own TLS handshake with the client (in the role of fake server) and a separate one with the real server (as fake client). Attacker still reads everything.
Phase 3 — TLS with proper certificate verification. Client refuses the fake certificate (because it is signed by an unknown CA). Connection fails to establish; attack fails. Optionally show the real CA-signed certificate and successful negotiation.

Controls panel:

Buttons: Step / Play / Reset.
Phase tabs.
Toggle: "Show certificate chain" reveals the chain validation steps in Phase 3.
Toggle: "Show pinned certificate" shows certificate pinning catching even an attacker with a CA-signed fake certificate.

Visual style:

Client / Attacker / Server: rounded rectangles with appropriate icons.
Plaintext messages: visible bytes.
Encrypted messages: padlock icons.
Modified messages highlighted in red.

Learning objectives:

(Bloom — Understanding) Students explain how MITM works and what authentication adds.
(Bloom — Analyzing) Students decompose a TLS handshake into the steps that actually defeat MITM.
(Bloom — Evaluating) Students judge when certificate verification is sufficient and when pinning adds value.

Implement in pure p5.js with the existing MicroSim CSS theme.

12.9 Defense in Depth¶

No single security mechanism is perfect. A firewall that uses a vendor with a vulnerable version of the parser will let a crafted attack through. A TLS server with a bad cipher suite will be downgraded. A user will be tricked into clicking a malicious link. Defense in depth is the principle of layering many imperfect defenses so that an attacker who breaches one still faces others.

A typical enterprise applies defense in depth across several layers:

Perimeter. Firewalls, IDS/IPS, DDoS scrubbing.
Network segmentation. VLANs, subnets, micro-segmentation. An attacker who reaches one segment cannot freely reach others.
Authentication. Multi-factor authentication on every user account; certificates on every device.
Encryption. TLS for application traffic; IPsec for site-to-site.
Endpoint security. Host firewalls, antivirus/EDR, full-disk encryption.
Monitoring. Logging from every layer aggregated into a SIEM (Security Information and Event Management) system.
Operational practices. Patch management, least privilege, incident response runbooks.

Each layer reduces the probability or impact of a breach. The goal is not prevention of every attack (impossible) but detection and response before significant damage is done.

12.10 Zero-Trust Architectures¶

The traditional security model trusted everything inside the network perimeter and distrusted everything outside. The implicit assumption — "if you're inside, you're authorized" — has aged poorly. Mobile devices, cloud services, contractors, and home networks have made the perimeter porous. Modern attacks routinely start by phishing one user, then move laterally across the trusted internal network.

Zero-trust networking rejects the implicit trust of the perimeter. Every request must be authenticated and authorized, every time, regardless of where it originates. The core principles:

Verify explicitly. Always authenticate and authorize based on user identity, device posture, location, and other context.
Assume breach. Design as if an attacker is already inside the network. Encrypt everything; segment everything.
Least privilege access. Grant only the access required for the task at hand, and only for the duration needed.
Continuously validate. Re-evaluate trust as conditions change, not just at login.

In practice, zero-trust replaces the network perimeter with an identity-aware proxy or zero-trust gateway. Every request to an internal service is mediated by the gateway, which checks user identity, device health, and access policy before forwarding. Google's BeyondCorp (2014–2017) was the most influential public deployment; many subsequent products (Cloudflare Access, Microsoft Entra Private Access, Tailscale) implement variants of the same idea.

Zero trust is not a single product — it is an architectural choice with implications across identity management, network design, application architecture, and operations. Its adoption is uneven; some organizations have transitioned fully, others combine zero-trust elements with traditional perimeter defenses.

12.11 Putting It Together: Securing a Web Service¶

A modern web service combines essentially every element of this chapter:

TLS at the edge. Every public connection terminates TLS at a load balancer or reverse proxy. The server presents an X.509 certificate signed by a trusted CA (or, increasingly, by Let's Encrypt automatically).
DDoS protection. Traffic flows through a scrubbing service (Cloudflare, AWS Shield) that absorbs volumetric attacks before they reach the origin.
Web application firewall. A WAF inspects HTTP requests for common attack patterns (SQL injection, XSS, path traversal) and blocks them.
Authentication. Users authenticate with multi-factor; service accounts authenticate with mutual TLS or short-lived tokens.
Internal segmentation. Web servers, application servers, and databases live on separate subnets with firewall rules permitting only the minimum required traffic between them.
Encrypted intra-service. Even on the trusted internal network, services authenticate to each other with mTLS or signed tokens.
Logging and SIEM. Every component logs to a central system; security analysts review alerts and run threat-hunting queries.
Patch management. Operating systems, libraries, and applications get patched on a defined cadence; high-severity vulnerabilities trigger emergency patches.
Incident response. Runbooks and tabletop exercises prepare the team for security incidents; on-call rotations ensure 24/7 coverage.

Each layer addresses different threats at different layers, and each is imperfect. Together, they make breaking the system expensive for an attacker — which is the realistic goal of network security.

If security feels like a lot — that's because it is

Buzz cheering you on Cryptography, certificates, firewalls, attacks, defense-in-depth — every one of these is its own subdiscipline. One hop at a time. Most networking jobs do not require deep crypto knowledge; they require knowing what each layer is supposed to do, recognizing its failures, and asking the right questions when something looks wrong. Start by reading the certificate that protects this textbook's website. The vocabulary in this chapter is enough to understand most of what you see.

12.12 Key Takeaways¶

Network security is the most operationally consequential part of modern networking. Before moving on, make sure you can answer the following without looking back:

Name the three classical security goals.
Compare symmetric and public-key encryption on speed, key management, and typical use.
What is a hash function? What is a digital signature?
What is an X.509 certificate? What is a certificate authority? How does a certificate chain work?
Walk through the TLS 1.3 handshake.
What does IPsec provide that TLS does not? What does TLS provide that IPsec does not?
Compare a packet filter, a stateful firewall, and a next-generation firewall.
What is the difference between IDS and IPS?
For each of the six attacks in the table (IP spoof, MITM, DDoS, replay, SYN flood, ARP spoof), name a typical defense.
What is defense in depth, and why is it necessary?
What is zero-trust networking? Why has it gained popularity?

If any of those answers feel shaky, re-read the corresponding section before continuing to Chapter 13, where we move on to the application layer — the protocols (DNS, HTTP, SMTP, SSH, WebSocket, gRPC) that the security infrastructure of this chapter is protecting.

Sealed and verified

Buzz celebrating You can now explain why the lock icon in your browser is meaningful, and what it does not tell you. The next chapter reveals what those encrypted bytes actually are: HTTP, DNS, SMTP, and friends. Follow the packet.