What Is a Network Packet?
When you send data over a network — whether you're loading a web page, sending an email, or streaming a video — that data doesn't travel as one continuous block. Instead, it's broken into small, discrete units called packets. Each packet is a self-contained bundle that includes both the data you're sending and the control information needed to get it from your device to its destination.
Think of it like sending a book through the mail: you wouldn't stuff the entire book in one envelope. You'd tear it into pages, put each page in its own envelope with an address label, and mail them all separately. Each envelope is a packet. The postal service doesn't need to know what's on every page — it just needs to deliver each envelope to the right address. The internet works the same way.
Every packet has two main parts:
- Header: Control information that tells network equipment where the packet is going, where it came from, and how to handle it. The header is read by every router and switch along the path.
- Payload: The actual data you're sending — a piece of a web page, an email, a video frame, anything. This is the content that the header exists to deliver.
ASCII Diagram: Basic Packet Structure
┌──────────────────────────────────────────────────────────────────────┐ │ GENERIC NETWORK PACKET │ ├─────────────────┬─────────────────┬───────────────────────────────────┤ │ │ │ │ │ HEADER │ HEADER │ PAYLOAD │ │ (Layer 3) │ (Layer 4) │ (Application Data) │ │ │ │ │ ├─────────────────┼─────────────────┼───────────────────────────────────┤ │ │ │ │ │ Source IP │ Source Port │ │ │ Destination IP │ Dest Port │ The actual content: │ │ Protocol │ Sequence # │ HTTP request, │ │ TTL │ Flags │ email body, video frame, │ │ Flags │ Checksum │ file chunk, etc. │ │ Header Length │ Offset │ │ │ │ │ │ │ [20-60 bytes] │ [20 bytes] │ [Up to ~65,535 - headers] │ │ │ │ │ └─────────────────┴─────────────────┴───────────────────────────────────┘ Layer 2 (Data Link) adds its own header + trailer: ┌─────────────┬───────────────────────────────────┬─────────┐ │ L2 HEADER │ PAYLOAD (L3-L7) │L2 TRAILER│ │ (Ethernet) │ │ (FCS) │ ├─────────────┴───────────────────────────────────┴─────────┤ │ Dest MAC │ Source MAC │ EtherType/Len │ │ │ (6 bytes)│ (6 bytes) │ (2 bytes) │ 4 bytes CRC │ └─────────────────────────────────────────────────────────────┘ Full stacked view: ┌────────┬────────┬────────┬─────────────────────────────┬────────┐ │ L2 HDR │ L3 HDR │ L4 HDR │ APPLICATION DATA │ L2 FCS │ │ Ethernet│ IPv4 │ TCP │ │ (CRC) │ ├────────┴────────┴────────┴─────────────────────────────┴────────┤ │ │ │ The complete Ethernet frame that actually gets transmitted │ │ on the wire (or, in WiFi's case, radiated as radio waves) │ │ │ └────────────────────────────────────────────────────────────────────┘
Packet Headers: IP, TCP, and UDP
Each layer of the network stack adds its own header to the packet. Understanding what each header does helps you understand how WiFi attacks work — because attackers who manipulate these headers can redirect traffic, intercept connections, or disrupt communication.
IP Header (Layer 3 — Internet Protocol)
The IP header is the fundamental addressing mechanism of the internet. Every device connected to the internet has an IP address — a unique number that identifies it on the network. The IP header tells routers where to send the packet.
┌─────────────────────────────────────────────────────────────────┐
│ IPv4 HEADER (20 bytes) │
├──────┬──────┬───────┬────────────────┬─────────────────────────┤
│ Ver │ IHL │ TOS │ Total Length (16 bits) │
├──────┴──────┴───────┼────────────────┼─────────────────────────┤
│ Identification (16)│ Flags (3) │ Fragment Offset (13) │
├─────────────────────┴───────────┴──────────────────────────────┤
│ TTL (8) │ Protocol (8) │ Header Checksum (16) │
├───────────────────┴────────────────┴──────────────────────────┤
│ Source IP Address (32 bits) │
├────────────────────────────────────────────────────────────────┤
│ Destination IP Address (32 bits) │
├────────────────────────────────────────────────────────────────┤
│ Options (0-40 bytes, optional) │
└────────────────────────────────────────────────────────────────┘
Key fields:
• Version: 4 (for IPv4) or 6 (for IPv6)
• IHL: Header Length — how many 32-bit words the header is
• TTL: Time To Live — decremented at each router; packet
dropped when TTL reaches 0. Prevents routing loops.
• Protocol: Which protocol is in the payload (6=TCP, 17=UDP, 1=ICMP)
• Source IP: The device that sent this packet
• Destination IP: The device this packet is destined for
TCP Header (Layer 4 — Transmission Control Protocol)
TCP is the protocol that makes the internet reliable. Where IP just delivers packets, TCP ensures they arrive in order, without duplicates, and without errors. It's the protocol behind web browsing, email, SSH, and most other important internet services.
┌─────────────────────────────────────────────────────────────────┐
│ TCP HEADER (20 bytes) │
├──────────┬──────────┬───────────────────────────────────────────┤
│ Source │ Dest │ │
│ Port │ Port │ Sequence Number (32 bits) │
├──────────┴──────────┼───────────────────────────────────────────┤
│ Acknowledgment (32) │ │
├─────────┬───────────┼────────┬──────────┬────────────────────────┤
│ Hdr Len │ Flags │ Window │ Checksum │ Urgent Pointer │
│ (4 bits)│ (9 bits) │(16 b) │ (16 b) │ (16 b) │
├─────────┴───────────┴────────┴──────────┴────────────────────────┤
│ Options (0-40 bytes, optional) │
└─────────────────────────────────────────────────────────────────┘
Key fields:
• Source Port: Which application on the sender initiated this
• Dest Port: Which application on the receiver should receive it
• Sequence Number: Position of this byte in the data stream
• Acknowledgment: "I have received up through byte N" — enables reliability
• Flags (key ones):
SYN "I want to establish a connection" (3-way handshake)
ACK "I acknowledge your previous message"
FIN "I want to close the connection"
RST "Something is wrong — abort immediately"
PSH "Deliver this data to the application immediately"
• Window Size: How much data the receiver is willing to buffer
TCP 3-WAY HANDSHAKE:
┌──────────┐ SYN ┌──────────┐
│ Client │ ──────────────────► │ Server │
│ │ │ │
│ │ ◄────────────────── │ │
│ │ SYN-ACK │ │
│ │ │ │
│ │ ──────────────────► │ │
│ │ ACK │ │
└──────────┘ └──────────┘
Connection established. Data transfer can now begin.
UDP Header (Layer 4 — User Datagram Protocol)
UDP is the lightweight alternative to TCP. It doesn't establish a connection, doesn't guarantee delivery, and doesn't ensure ordering. What it does provide is speed — UDP is used for real-time applications where a missing packet is better than a late one.
┌─────────────────────────────────────────────────────────────────┐ │ UDP HEADER (8 bytes) │ ├──────────────────────┬──────────────────────────────────────────┤ │ Source Port │ Destination Port │ ├──────────────────────┴──────────────────────────────────────────┤ │ Length │ Checksum │ └─────────────────────┴───────────────────────────────────────────┘ Key difference from TCP: UDP has no handshake, no sequence numbers, no acknowledgment, no window size. It's "send and pray." Used for: DNS queries, DHCP, VoIP (voice calls), video streaming, online gaming, SNMP. When a VoIP call has packet loss, you hear a brief skip or glitch — that's UDP not bothering to retransmit the missing packet.
How WiFi Frames Work (802.11 Frame Types)
WiFi operates on Layer 2 of the network stack — the Data Link layer — and uses its own frame format defined by the 802.11 standard. These are not the same as Ethernet frames, though they serve a similar purpose. WiFi frames come in three main types:
Management Frames
Management frames are used to join and leave WiFi networks, authenticate with access points, and handle the mechanics of WiFi connectivity. They're the frames that make WiFi "just work" — the invisible handshake that happens every time you connect to a network.
┌─────────────────────────────────────────────────────────────────┐ │ 802.11 MANAGEMENT FRAME │ ├─────────┬─────────┬──────────┬───────────┬───────────────────────┤ │ Frame │ Dur/ │ Addr 1 │ Addr 2 │ Addr 3 │ │ Control │ ID │ (RA/Rx) │ (TA/Tx) │ (BSSID/Dest/Source) │ │(2 bytes)│(2 bytes)│(6 bytes) │(6 bytes) │ (6 bytes) │ ├─────────┴─────────┴──────────┴───────────┴───────────────────────┤ │ Sequence │ │ │ Control │ Frame Body (variable) │ │ (2 bytes) │ (SSID, supported rates, channel, etc.) │ ├───────────┴───────────────────────────────────────────────────────┤ │ FCS (Frame Check Sequence) │ │ (4 bytes, CRC-32) │ └─────────────────────────────────────────────────────────────────┘ Common Management Frame Subtypes: • 0000: Association Request — "I want to join your network" • 0001: Association Response — "OK, here's your association ID" • 0010: Reassociation Request — "I'm moving to a better AP" • 0011: Reassociation Response • 0100: Probe Request — "Is anyone there?" (active scanning) • 0101: Probe Response — "I'm here, here's my info" • 0110: Beacon — "I'm here, I'm here, I'm here..." (AP) • 1000: Disassociation — "We're done, I'm leaving" • 1010: Authentication — "Here's my credentials" • 1011: Deauthentication — "You are no longer authorized" BEACON FRAME (the most common WiFi frame — sent ~10x/second per AP): ┌──────────┬─────────────┬───────────────────────────────────────┐ │ Beacon │ SSID: "Free WiFi" │ │ │ BSSID: AA:BB:CC:DD:EE:FF │ │ │ Channel: 6 │ │ │ Encryption: WPA2-PSK │ │ │ Supported rates: 1, 2, 5.5, 11, 54 Mbps │ │ │ ... (lots more info) │ └──────────┴───────────────────────────────────────────────────┘ This is what your phone scans when it looks for known networks.
Control Frames
Control frames assist in the delivery of data frames. They handle things like acknowledging successful transmissions and controlling access to the wireless medium.
Common 802.11 Control Frame Subtypes: • 1011: RTS (Request to Send) — "I want to transmit, everyone else shut up" • 1100: CTS (Clear to Send) — "OK, you're clear to transmit" • 1101: ACK (Acknowledgment) — "I got that frame, it was valid" The RTS/CTS exchange is used to avoid the "hidden node problem" — when two stations can both see the AP but can't see each other. By exchanging RTS/CTS, they coordinate access to the shared medium.
Data Frames
Data frames carry the actual network layer packets — the IP packets and their TCP/UDP payloads that make up your web browsing, email, and everything else. These are the frames that WiFi encryption protects.
┌─────────────────────────────────────────────────────────────────┐ │ 802.11 DATA FRAME │ ├─────────┬─────────┬──────────┬───────────┬───────────────────────┤ │ Frame │ Dur/ │ Addr 1 │ Addr 2 │ Addr 3 │ │ Control │ ID │ (RA/Rx) │ (TA/Tx) │ (BSSID/Dest/Source) │ ├─────────┴─────────┴──────────┴───────────┴───────────────────────┤ │ Sequence │ │ │ Control │ Encrypted Payload (IP packet + padding) │ ├───────────┴───────────────────────────────────────────────────────┤ │ FCS (4 bytes) │ └─────────────────────────────────────────────────────────────────┘ Addr field usage depends on the From DS / To DS bits in Frame Control: From DS=0, To DS=0: Ad-Hoc or IBSS (peer-to-peer) Addr1 = Destination MAC Addr2 = Source MAC Addr3 = BSSID From DS=0, To DS=1: Station to AP (uplink) Addr1 = BSSID (AP MAC) Addr2 = Source MAC (transmitting station) Addr3 = Destination MAC From DS=1, To DS=0: AP to Station (downlink) Addr1 = Destination MAC Addr2 = BSSID (AP MAC) Addr3 = Source MAC From DS=1, To DS=1: AP to AP (wireless distribution system) Used when frames cross between APs over a wired backbone.
What Is Encryption at the Packet Level?
Encryption is the process of converting data into a form that cannot be read by anyone who doesn't have the right key. At the packet level, encryption means that the payload of each WiFi frame — the actual data you're sending — is transformed into ciphertext before it's transmitted over the air.
Here's the critical point: WiFi encryption protects the payload of the data frames, not the WiFi frame headers themselves. The WiFi header (with the MAC addresses, sequence numbers, and control information) is always transmitted in the clear. Only the frame body — containing your IP packets — is encrypted.
This means:
- An attacker can see that you're communicating with a particular access point
- An attacker can see how much traffic is flowing and when
- An attacker can see which WiFi channel and what data rate you're using
- But an attacker cannot see what you're sending — your web requests, emails, passwords, data
What Encryption Actually Does (and Doesn't Do)
WITHOUT WiFi ENCRYPTION (Open Network): ┌──────────────────────────────────────────────────────┐ │ Header (MACs visible) │ Payload: "GET /bank HTTP/1.1" │ ← ATTACKER SEES EVERYTHING │ │ Host: mybank.com │ │ │ Cookie: session=abc123... │ └──────────────────────────────────────────────────────┘ WITH WPA2 ENCRYPTION: ┌──────────────────────────────────────────────────────┐ │ Header (MACs visible) │ Encrypted Payload: │ ← ATTACKER SEES METADATA │ │ [0x3F 0x8A 0x21 ...] │ but NOT content └──────────────────────────────────────────────────────┘ WITH WPA2 + HTTPS: ┌──────────────────────────────────────────────────────┐ │ Header (MACs visible) │ Encrypted Payload: │ ← ATTACKER SEES: │ │ [encrypted HTTPS data] │ • Connection to mybank.com │ │ │ • Amount of data │ │ │ • Timing patterns │ │ │ NOT the actual content └──────────────────────────────────────────────────────┘
WEP Encryption and Why It Fails
Wired Equivalent Privacy (WEP) was the original WiFi encryption standard, introduced in 1997 as part of the original 802.11 standard. It was designed to provide WiFi with privacy equivalent to a wired network. It catastrophically failed at this goal.
How WEP Works (Briefly)
WEP uses the RC4 stream cipher in a configuration called "IV-based RC4." Here's how it works:
- The shared secret key (the WiFi password) is combined with a 24-bit Initialization Vector (IV) to create a per-packet RC4 key.
- The RC4 cipher generates a "keystream" — a stream of pseudorandom bytes.
- The keystream is XORed with the plaintext data payload to produce the ciphertext.
- The IV is prepended to the ciphertext so the receiver can decrypt it.
WEP ENCRYPTION:
┌──────────────────┐
│ Shared Secret Key │ + ┌───────────────┐
│ (40 or 104 bits)│ │ IV (24 bits) │ ← Sent in the clear!
└──────────────────┘ └───────────────┘
│ │
└──────────┬──────────────┘
▼
RC4 Key = (IV || Shared Key)
│
▼
RC4 Keystream Generator
│
▼
Keystream Bytes
│
┌──────────┴──────────┐
│ │
▼ ▼
Plaintext Data XOR Ciphertext
│ │
│ └──────┐
│ │
└─────────────────────────────┼──── Transmitted Frame:
│
┌─────────────┴─────────────┐
│ IV (24 bits) || Ciphertext │
│ (in the clear) (encrypted)│
└────────────────────────────┘
Why WEP Is Fundamentally Broken
The fatal flaw in WEP is the combination of two things:
- The IV is too short and reused: A 24-bit IV has only 16,777,216 possible values. At a busy access point transmitting at 54 Mbps, a new IV is needed for every frame. At 1500-byte frames, that's roughly 4,500 frames per second — meaning the entire IV space is exhausted in about an hour. When IVs are reused, the same keystream is used to encrypt two different plaintexts. XORing the two ciphertexts together cancels out the keystream, and the attacker can recover both plaintexts.
- No per-packet authentication: WEP doesn't have a built-in integrity check for the payload. An attacker can flip bits in an encrypted WEP payload in a controlled way, and the change will appear at the receiver with no way to detect tampering. This enables the "ChopChop attack," which can decrypt WEP traffic byte by byte without cracking the key.
With freely available tools like aircrack-ng and wifite, cracking a WEP key requires capturing as few as 20,000 frames — which can take as little as 5-10 minutes on an active network. Full key recovery in under a minute is achievable with enough traffic.
WPA/WPA2 TKIP vs. AES
WiFi Protected Access (WPA) was introduced in 2003 as a stopgap replacement for WEP while the 802.11i standard was being finalized. It was followed by WPA2 in 2004, which became the dominant WiFi encryption standard for over 15 years.
WPA: TKIP (Temporal Key Integrity Protocol)
WPA introduced TKIP as an improvement over WEP. TKIP attempts to fix WEP's worst problems:
- Per-packet key mixing: Instead of using the IV concatenated with the master key, TKIP mixes the IV with the master key in a more complex way that makes IV reuse less catastrophic.
- Michael algorithm: TKIP adds a Message Integrity Check (MIC) to detect forged packets — this makes ChopChop attacks much harder.
- Key rotation: WPA requires the Temporal Key (the per-session encryption key) to be changed frequently. The default is to rotate it every 10,000 packets.
TKIP was an improvement over WEP, but it was already considered deprecated when it was introduced. In 2008, researchers Erik Tews and Martin Beck discovered attacks that could recover WPA-TKIP keys in roughly 12-15 minutes. TKIP should not be used.
WPA2: CCMP (AES-based)
WPA2 made the transition to a fundamentally different cipher: the Advanced Encryption Standard (AES). Where RC4 (WEP/TKIP) is a stream cipher with known weaknesses, AES is a block cipher that has been rigorously analyzed by cryptographers worldwide and is considered extremely strong.
WPA2 ENCRYPTION (CCMP mode): ┌──────────────────────────────────────────────────────────────┐ │ WPA2 4-WAY HANDSHAKE │ ├──────────────────────────────────────────────────────────────┤ │ │ │ AP sends ANonce to client │ │ ◄──────────────────────────────────── AP: "Here's a │ │ random number" │ │ │ │ Client generates SNonce, derives PTK (Pairwise Transient Key)│ │ PTK = PRF(PMK + ANonce + SNonce + MAC_AP + MAC_Client) │ │ PMK = derived from PSK (WiFi password) │ │ PTK includes: KCK (Key Confirmation Key) │ │ TEK (Temporal Encryption Key) │ │ TMK (Temporary MIC Key) │ │ │ │ Client sends SNonce + MIC to AP │ │ ──────────────────────────────────────► Client: "Here │ │ are my numbers" │ │ │ │ AP derives PTK (same process), verifies MIC │ │ AP sends GTK (Group Temporal Key) + MIC │ │ ◄──────────────────────────────────── AP: "Here's the │ │ group key too" │ │ │ │ Client sends ACK │ │ ──────────────────────────────────────► Client: "Got it" │ │ │ │ Connection established. All data frames encrypted with TEK. │ │ │ └──────────────────────────────────────────────────────────────┘
WPA2 with AES-CCMP is the standard that protects most WiFi networks today. It is substantially more secure than WEP or WPA-TKIP, and with a strong password, WPA2 is genuinely difficult to break.
The Weakest Link: The Password
The security of WPA2-PSK (Pre-Shared Key — the WPA2 most homes and small businesses use) depends entirely on the strength of the WiFi password. Here is why:
- The WiFi password is run through a function called PBKDF2 (Password-Based Key Derivation Function 2) to produce the Pairwise Master Key (PMK).
- The PMK is used in the 4-way handshake, but it is never transmitted over the air. The handshake uses the ANonce and SNonce (random numbers exchanged in the clear) to derive the actual encryption key (PTK).
- An attacker can capture the 4-way handshake by forcing a client to reconnect (deauth attack), then attempt to crack the password offline by trying candidate passwords against the handshake data.
- With a weak password, this is fast. With a strong, random password, it becomes computationally infeasible.
WPA3 and Its Improvements
WPA3, finalized in 2018, is the successor to WPA2. It addresses several fundamental weaknesses in WPA2 and introduces new protections. It is slowly becoming the default on new devices, but WPA2 remains dominant in the installed base.
WPA3-Personal: SAE and Forward Secrecy
WPA3 replaces the PSK handshake with a new protocol called SAE (Simultaneous Authentication of Equals), which is based on a different cryptographic primitive called a Password-Authenticated Key Exchange (PAKE). The key improvement is that SAE provides forward secrecy — even if an attacker later learns your WiFi password, they cannot decrypt past sessions that were captured while you were connected.
WPA2-PSK vs WPA3-SAE: WPA2-PSK: Password → PMK (stored on AP and client) If attacker learns password → can decrypt ALL past traffic captured (because the PMK derived from password = same every time) WPA3-SAE: Password → run through SAE exchange with random numbers → Session-specific key (no stored long-term key equivalent) If attacker learns password → CANNOT decrypt past sessions (forward secrecy — each session's key is unique)
WPA3-Enterprise: 192-bit Security Suite
WPA3-Enterprise requires 192-bit minimum security in its cryptographic suite, up from the 128-bit minimum in WPA2. It also mandates the use of Protected Management Frames (PMF) — which protects the management frames that WPA2 left unprotected, preventing deauthentication attacks that relied on forged management frames.
The Dragonblood Vulnerability (2019)
Shortly after WPA3's announcement, security researchers Mathy Vanhoef and Eyal Ronen published the "Dragonblood" attacks, which demonstrated that early WPA3 implementations using SAE were vulnerable to both passive dictionary attacks (if the password was weak) and active attacks that could recover session keys. Most affected devices have since been patched. WPA3 with all recommended configurations enabled remains secure.
Encryption In Transit vs. At Rest
Understanding the difference between "encryption in transit" and "encryption at rest" is critical for understanding your actual security posture on WiFi networks.
Encryption in Transit
Encryption in transit protects data while it's moving across a network — from your device to a server, through multiple routers and network segments along the way. WiFi encryption (WPA2/WPA3) is encryption in transit for the wireless segment only. HTTPS (TLS) is encryption in transit for the entire path from your browser to the web server.
When you use public WiFi without a VPN:
- The WiFi segment is encrypted (if using WPA2/WPA3)
- From the access point to the internet: typically NOT encrypted (unless the destination uses HTTPS)
- An attacker on the same WiFi network can see your traffic before it's encrypted by HTTPS
When you use a VPN on public WiFi:
- The entire path from your device to the VPN server is encrypted (including the WiFi segment)
- An attacker on the WiFi network sees only encrypted VPN traffic
Encryption at Rest
Encryption at rest protects data that is stored — on a hard drive, a server's disk, a database. This is a different threat model: it's about protecting data if a device is stolen, a server is breached, or a hard drive is decommissioned without being properly wiped.
Common at-rest encryption technologies:
- BitLocker (Windows): Full-disk encryption using AES-128 or AES-256
- FileVault (macOS): Apple's full-disk encryption
- LUKS (Linux): Linux Unified Key Setup for disk encryption
- dm-crypt: Transparent block device encryption for Linux
- Cloud storage encryption: Most providers offer server-side encryption, but you can also use client-side encryption where only you have the keys
The key insight: Encryption at rest and encryption in transit protect against different threats. Your data can be encrypted at rest on a server but completely exposed in transit. Both matter, but for WiFi security specifically, in-transit encryption is the more immediate concern.
WiFi Encryption (WPA2) vs. HTTPS (TLS)
These are two different layers of encryption that protect different segments of your communication path. Understanding both — and how they work together — is essential for understanding your real security posture on WiFi.
FULL PATH: Your Device → WiFi → Router → Internet → Web Server
└──────────┘ └───────────────────────────────┘
WiFi segment Rest of the internet path
(WPA2/WPA3) (HTTPS/TLS or unencrypted)
CASE 1: Public WiFi, NO VPN, NO HTTPS
┌─────────────────────────────────────────────────────────────────┐
│ YOUR WiFi AP Router ISP Destination Server │
│ DEVICE ◄──────────► │
│ │ [OPEN or │
│ │ WEP] │
│ │ │ │
│ │ Encryption Encryption │
│ │ ends here begins here │
│ │ │ │
│ │ ▼ │
│ │ ═══════════════════════════════════════════════════ │
│ │ Everything in between is UNENCRYPTED (plaintext) │
│ │ ATTACKER ON WiFi CAN: │
│ │ • See all traffic │
│ │ • Capture passwords, cookies, data │
│ └────────────────────────────────────────────────────────────────┘
CASE 2: Public WiFi, NO VPN, WITH HTTPS
┌─────────────────────────────────────────────────────────────────┐
│ YOUR WiFi AP Router ISP Destination Server │
│ DEVICE ◄──────────► ◄──────►│
│ │ [OPEN or │
│ │ WEP] │
│ │ │ │
│ │ Encrypted End-to-end │
│ │ by WiFi Encrypted │
│ │ encryption by TLS │
│ │ │ │
│ │ ▼ │
│ │ ═══════════════════════════════════════════════════ │
│ │ ATTACKER ON WiFi CAN: │
│ │ • See that you're connecting to example.com │
│ │ • See timing and volume of traffic │
│ │ • NOT see actual content (it's TLS-encrypted) │
│ └────────────────────────────────────────────────────────────────┘
CASE 3: Public WiFi + VPN
┌─────────────────────────────────────────────────────────────────┐
│ YOUR WiFi AP Router ISP VPN Server Internet │
│ DEVICE ◄──────────► ◄────────────────────────────► │
│ │ [OPEN] [Entire path encrypted by VPN tunnel] │
│ │ │ │
│ │ Encrypted Decrypted │
│ │ by WiFi Entire VPN tunnel by VPN │
│ │ encryption is encrypted server │
│ │ │ │
│ │ ▼ │
│ │ ═══════════════════════════════════════════════════ │
│ │ ATTACKER ON WiFi CAN: │
│ │ • See that you're connecting to a VPN server │
│ │ • See encrypted data volume and timing │
│ │ • NOT see what sites you're accessing │
│ │ • NOT see any application-level content │
│ └────────────────────────────────────────────────────────────────┘
What Happens When Encryption Fails
Encryption is strong, but it's not unbreakable. Understanding how encryption fails helps you understand the real risk profile of different scenarios and why defense-in-depth — multiple layers of security — matters.
How WPA2 Encryption Can Be Defeated
- Weak password: The most common WPA2 compromise. If your WiFi password is "password123" or "JohnSmith2019", a cracking rig can break it in hours or less. Use a strong, random password (16+ characters, stored in a password manager).
- KRACK (Key Reinstallation Attack, 2017): A fundamental protocol flaw in the WPA2 standard itself. By capturing and replaying a specific handshake message, an attacker could reinstall a key that had already been used, enabling decryption of past and future traffic. Patches to both APs and clients have largely mitigated this, but unpatched devices remain vulnerable.
- WPS PIN brute-forcing: If WPS is enabled on a WPA2 router, the 8-digit PIN can be brute-forced in hours. Once the PIN is recovered, the WPA2 password can be derived. Disable WPS.
- Evil twin / MITM: An attacker can set up a fake access point and perform a man-in-the-middle attack, capturing traffic before it's encrypted or after it's decrypted. HTTPS protects against this for web traffic, but non-HTTPS traffic remains vulnerable.
How HTTPS Can Be Defeated
- Certificate spoofing / MITM: If an attacker can install their own root certificate on your device (through malware, corporate MDM, or physical access), they can perform a MITM attack that decrypts HTTPS traffic. This is why you should never accept unknown certificate warnings — they may indicate an active attack.
- SSL stripping: An attacker on the network can intercept the initial HTTP request and prevent the browser from upgrading to HTTPS. Modern browsers largely mitigate this with HSTS (HTTP Strict Transport Security), which tells browsers to always use HTTPS for specific sites. However, first-visit attacks remain possible without HSTS preloading.
- Compromised certificate authorities: Certificate authorities (CAs) are the trusted entities that sign website certificates. If a CA is compromised (as happened with DigiNotar in 2011), attackers can obtain valid certificates for any domain, enabling convincing MITM attacks.
- Protocol downgrade attacks: Forcing a connection to use an older, weaker TLS version (TLS 1.0, TLS 1.1) or weak cipher suites that are easier to break. Modern browsers and servers now mandate TLS 1.2 or higher, but legacy systems may be vulnerable.