Every packet on the internet has two parts: a header that says where it is going, and a payload that carries the actual data. Ordinary routing (sometimes called shallow inspection) only looks at the header, mostly the source and destination IP addresses and ports. That is all a router needs to forward traffic. Deep packet inspection, or DPI, goes further and examines the payload, applying rules based on what the content appears to be rather than just where it is headed.
DPI is a general capability, not a single product. The same technique sits behind uses that most people would call reasonable and uses that most people would call surveillance. Understanding what it can and cannot see is the difference between guessing at your exposure and knowing it.
What DPI is used for
The common deployments fall into a few categories:
- Traffic management. An internet provider classifies traffic as video, gaming, or file sharing, and prioritizes or throttles each class. This is where net neutrality debates live.
- Enterprise security and data loss prevention. A corporate network inspects outbound traffic for malware signatures or for confidential data leaving the building.
- Censorship and filtering. A national or provider-level firewall blocks or degrades traffic to specific services, sometimes by content pattern rather than by IP.
- Advertising and injection. Some providers have historically used DPI to insert tracking identifiers or ads into unencrypted web pages.
- Lawful intercept. Interception systems built into carrier infrastructure to comply with legal orders. Our piece on the Salt Typhoon intrusions covers what happens when those systems are themselves compromised.
What encryption takes away from DPI
When traffic is encrypted end to end, the payload becomes unreadable to anything in the middle. A DPI box watching an HTTPS connection cannot see the URL path you requested, the contents of the page, the text of a form you submitted, or anything else inside the TLS tunnel. This is a real and significant reduction in what an inspecting network learns. It is the reason the move to HTTPS across the web mattered so much for privacy.
The historical ad-injection and page-rewriting uses of DPI died as HTTPS became universal, because there is no longer a plaintext page to modify in transit. The same is true for content-signature censorship: you cannot filter on a keyword you cannot read.
Encryption hides the contents of your traffic, not the fact of it. A DPI system can still see who you are connecting to, roughly when, how much data flows in each direction, and the timing pattern of that flow. For many surveillance purposes, that metadata is enough.
What still leaks through the tunnel
Even a perfectly encrypted connection exposes a surprising amount of structure. The main leaks:
The SNI field
When your browser opens a TLS connection, it sends a Server Name Indication (SNI) field telling the server which website it wants. Historically this was sent in cleartext, before encryption is established, so a DPI box could read the hostname of every site you visited even over HTTPS. This is the single most valuable field DPI-based censors relied on. The fix, Encrypted Client Hello (ECH), wraps that field in encryption, but adoption is still uneven and some networks block connections that use it.
DNS lookups
Before you connect to a site, your device usually asks a DNS server for its address, and classic DNS is unencrypted. A DPI system can read those lookups directly, building a log of every domain you resolve. Encrypted DNS transports (DNS over HTTPS and DNS over TLS) close this specific leak by hiding the query from the local network.
Destination addresses
The destination IP is on the outside of the packet and cannot be hidden from your provider without a tunnel like a VPN or Tor. Even with encrypted SNI and encrypted DNS, the IP you connect to is visible, and for many services the IP maps back to a single company.
Traffic fingerprints
The size and timing of packets form a pattern. Loading a specific web page produces a recognizable sequence of request and response sizes. The TLS handshake itself carries a fingerprint (the ordering of cipher suites and extensions) that identifies the client software, a technique called JA3 and JA4 fingerprinting. Video streams, voice calls, and messaging apps each have distinctive traffic shapes. This kind of analysis, covered in our traffic analysis piece, works entirely on metadata and is unaffected by how strong your encryption is.
The escalation: DPI versus obfuscation
In places where DPI is used for censorship, the relationship becomes an arms race. Censors move from blocking by IP, to blocking by SNI, to detecting the statistical shape of circumvention protocols. Circumvention tools respond by disguising their traffic as something ordinary.
This is the design goal behind pluggable transports like obfs4, and behind techniques such as domain fronting, which hides the true destination behind a large shared platform. Tools such as Tor bridges exist precisely because a censor's DPI can otherwise recognize and block a default Tor connection. The frontier now is not hiding content, which encryption already does, but hiding the fact that you are using a particular tool at all.
| What DPI wants to see | Countermeasure |
|---|---|
| Page contents, form data, URLs | HTTPS / TLS 1.3 (already effective) |
| Which hostname you requested (SNI) | Encrypted Client Hello, where supported |
| Which domains you look up | DNS over HTTPS or DNS over TLS |
| Destination IP address | VPN or Tor (moves the visible endpoint) |
| That you are using a circumvention tool | Pluggable transports, obfuscation, bridges |
| Traffic size and timing patterns | Padding and cover traffic (costly, rarely default) |
Putting it in perspective
The practical picture for most people is this. On a normal home or mobile connection, DPI can build a log of the domains and services you use and how much you use them, even though it cannot read your messages, your emails, or the pages you load. That metadata is valuable to advertisers, providers, and in some jurisdictions to the state. Encrypted DNS and encrypted SNI shrink the domain-level leak. A VPN or Tor shifts the visible endpoint but introduces a new party you have to trust, a tradeoff our VPN limitations piece looks at directly.
The clean mental model: encryption protects the letter, not the envelope. DPI has largely lost the ability to read the letter. It still reads the envelope, and a great deal can be inferred from who you write to and how often.
Where Haven fits
Haven encrypts message and email content end to end on the device, so the payload is opaque to any DPI system on the path, using PGP for email and the MLS protocol for group chat. That protects what you say. It does not, by itself, hide that you are using Haven from a network operator watching connection metadata, and we say so plainly rather than implying otherwise. Metadata resistance is a separate and harder problem, addressed by tools like Tor and by the padding techniques above. Knowing which layer solves which problem is the whole point: encryption handles content, and the envelope needs its own answer.