Safeguard
Research•

What is deep packet inspection (DPI) and how does encryption limit it?

Deep packet inspection reads packet contents, not just headers. Learn what DPI sees, why TLS 1.3 limits it, and the trade-offs of decrypting traffic.

Safeguard Security Team
4 min read

Deep packet inspection (DPI) examines the payload of network packets, not only the address and port in the header, so a device can classify applications, filter content or spot attack patterns. Encryption such as TLS hides the payload, so DPI on encrypted traffic needs either decryption or reliance on metadata.

How is DPI different from a basic packet filter?

A basic filter looks at the header: source, destination, port, protocol. It can say "allow TCP to port 443" and nothing about what travels inside. DPI reads further into the packet and, for many products, reassembles a whole stream to understand it.

That extra visibility supports several jobs: classifying traffic by application, matching known attack patterns, blocking certain content, and shaping bandwidth. NIST SP 800-41 Rev. 1, the firewall guide, describes firewall types by how deep they look, from simple packet filtering up to application-aware gateways.

What did encryption change?

IETF RFC 8404, "Effects of Pervasive Encryption on Operators", was written to describe how widespread encryption affects network practices. Its table of contents lists the affected functions: load balancing, differential treatment based on DPI, congestion management, performance-enhancing proxies, caching, compression and content filtering.

The core point is that when the payload is encrypted, middle boxes lose visibility they once relied on. TLS 1.3 (RFC 8446) is built to prevent eavesdropping, tampering and message forgery, and it encrypts more of the handshake than earlier versions did. A passive DPI device on the path sees addresses, timing and sizes, but not the application data.

What can DPI still see in encrypted traffic?

Metadata. Destination addresses, volume, timing patterns, and in some configurations the server name sent during connection setup. That is enough for coarse policy, such as allowing a known service and blocking an unknown one.

It is not enough to read a file upload or confirm what a request contained.

What are the options when you need to see inside?

Terminate and inspect. A proxy decrypts the session, inspects it and opens a new one to the destination. Clients must trust the proxy's certificate authority. This gives full visibility and also creates a place where all plaintext exists, which is a target.

Inspect at the endpoint. Put the checking on the device or in the application, where the data is already decrypted. This avoids a central decrypting point.

Use metadata and logging. Accept coarser visibility and invest in endpoint and application logs.

Each choice has privacy, legal and operational costs. Employee monitoring rules differ between jurisdictions, so involve legal and HR before you decrypt anything, and exclude categories such as banking or health traffic where policy requires.

What is a constructed example?

A company wants to stop staff uploading customer files to personal storage. A header-only filter cannot tell personal storage from approved storage on the same cloud. The team first blocks by destination and category using metadata. For the remaining risk they deploy inspection on managed laptops, where the browser data is visible before encryption, and they exempt health and finance sites from inspection.

How to check or apply this

  1. State the question you need DPI to answer: block an application, detect malware, prevent data loss. If metadata answers it, stop there.
  2. Measure how much of your traffic is encrypted. In most environments it is nearly all.
  3. If you decrypt, decide where, document exemptions, and protect the proxy and its private key like a crown asset.
  4. Confirm that legal and works council or privacy requirements are met.
  5. Test that decryption does not break pinned or mutual TLS services.
  6. Review whether the same control can be placed on the endpoint or in the application instead.

Quick check

Can DPI read HTTPS traffic?

Not without decrypting it. A passive device sees metadata only. A proxy that terminates TLS can read the content, if clients are configured to trust it.

Does TLS 1.3 make DPI useless?

No, but it narrows what a passive observer sees. DPI still works on unencrypted protocols and on traffic you decrypt at a proxy or endpoint.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.