Deepak Gupta

TLS Inspection with a Forward Proxy: What It Sees, What It Breaks

AppSec · advanced · 10 min read · last reviewed 2026-08-23

Deploy TLS inspection only with managed devices, a written bypass list, and a defensible retention policy. Here is what it sees, what it breaks, and where it stops working.

TL;DR

TLS inspection works only on devices whose certificate trust store you control, because the proxy presents a certificate signed by your own root certificate authority.
The bypass list is mandatory, not optional: banking, health, and legal categories, certificate-pinned applications, unmanaged devices, and your own software update channels.
Certificate pinning and unmanaged devices are hard stops rather than degradations. A pinned application fails outright instead of falling back to an inspectable connection.
Encrypted Client Hello became RFC 9849 in March 2026, but measured adoption is well under one percent of connections, so this is planned migration work rather than an emergency.
The retention policy is part of the deployment, not an afterthought. Decide what you log, for how long, who reads it, and what employees are told, before switching anything on.

Inspection works only where you control the trust store. Everything else must be bypassed on purpose.

Deploy TLS inspection only if you can satisfy all three preconditions: managed devices whose certificate trust store you control, a written bypass list agreed before you switch anything on, and a retention policy you can defend to the people whose traffic you are about to read. If you cannot supply all three, do not deploy it. A partial version of this control is not a smaller control, it is a broken one.

Should you inspect TLS at all?

Start by asking what you need that metadata cannot give you.

Destination-based policy already answers "where did this connection go", and it is cheap, private, and does not break anything. Inspection answers "what was inside it", and it is expensive, invasive, and breaks things. So the justification has to be a requirement that genuinely needs content:

Data loss prevention on web uploads and form submissions
Malware scanning of downloaded files
Detecting exfiltration inside API payloads that look ordinary from outside

If your actual requirement is "we want to block social media" or "we want a record of sites visited", you do not need inspection. Category-based blocking at the forward proxy or the DNS layer does that without decrypting anything.

How TLS inspection actually works

TLS inspection means the proxy terminates the encrypted connection, reads the plaintext, and opens a second encrypted connection onward. Two connections exist where the user believes there is one, and the proxy sits in the clear between them.

It works for exactly one reason: the client trusts a certificate authority you control. The proxy generates a certificate for the destination as the connection is made, signs it with your organization's root certificate authority, and the client accepts it because that root was installed on the device.

Say the uncomfortable part plainly: this is the same mechanism as a man-in-the-middle attack. Nothing in the mechanics distinguishes them. What distinguishes them sits outside the mechanics:

You installed the certificate authority yourself, on devices your organization owns.
You told the people using those devices that you are doing it.
You wrote down what you keep, for how long, and who can read it.

Those are governance facts, not technical ones, and they are the entire justification for the control. This is why the deployment checklist below is mostly not about configuration.

What you must put on the bypass list

Write this list before you turn inspection on, not after the first complaint.

Privacy and legal categories. Banking, health, and legal traffic. In several jurisdictions reading it is a legal problem, and in all of them it is a trust problem. Most gateway products ship these as pre-built categories precisely because everyone needs them.

Certificate-pinned applications. An application that pins has the expected certificate or public key compiled in and will reject yours no matter how correctly you installed the root. Critically, it does not fall back to an inspectable connection. It fails. Banking apps, many mobile applications, and a lot of software update channels pin. These must be bypassed by destination, and the list needs maintaining, because vendors add pinning without announcing it.

Unmanaged and personal devices. Inspection depends entirely on installing a root certificate authority. On a contractor's laptop or an employee's personal phone you cannot, and you should not want to. There is no partial version.

Software update and package channels. Operating system updates, package registries, and container registries frequently pin or use certificate checks that inspection disturbs. Breaking your own patching pipeline in the name of security is a bad trade.

Where inspection stops working

These are hard stops, not degradations. Plan around them rather than trying to defeat them.

What removes visibility	What actually happens	What to do instead
Certificate pinning	The application rejects your certificate and fails outright. It does not fall back.	Bypass by destination, and maintain the list, because vendors add pinning quietly.
Unmanaged device	You cannot install a root certificate authority, so there is nothing to inspect with.	Destination-based policy only, or require a managed device for the systems that need inspection.
QUIC and HTTP/3	Encryption is bound into the transport, and TCP-based inspection does not apply.	Block UDP 443 to force a TCP fallback today, and treat that as a shrinking answer.
Encrypted Client Hello	The server name is encrypted, so SNI-based identification at a firewall stops working.	No effect on an explicit terminating proxy. Move firewall policy onto identity, device posture, and DNS signals.

Certificate pinning. Covered above. The application fails rather than degrading, which at least makes the problem obvious.

Unmanaged devices. No trust store control, no inspection. This is the reason inspection alone is never a complete answer in an organization with contractors, personal devices, or acquisitions.

QUIC. QUIC carries HTTP/3 over UDP with encryption bound much more tightly into the transport than in the TLS-over-TCP model. The common gateway answer is to block UDP 443 and force clients back to TCP, where existing inspection works. That is workable today and deteriorating over time, because more traffic is moving to QUIC and not all of it falls back gracefully.

Encrypted Client Hello. ECH encrypts the first handshake message, including the Server Name Indication field that names the destination. SNI is what most firewalls use to identify a destination without decrypting anything, so ECH removes the cheapest visibility signal in the stack.

Get the ECH picture right, because the headlines overstate it. ECH was published as RFC 9849 in March 2026 as a Proposed Standard. Adoption is real but very small: measurements through 2025 found it on well under one percent of connections, and enterprise applications overwhelmingly do not use it. A browser only uses ECH when the destination publishes the necessary key in DNS, and many do not.

So: plan, do not panic. Two practical points.

If you run an explicit forward proxy that terminates TLS on managed devices, ECH changes nothing for you. You are not relying on SNI in the first place.
If your policy is built on SNI inspection at a firewall, start moving it onto identity, device posture, and DNS-layer signals now, as planned work over the next year or two. Those signals survive ECH. SNI will not.

The privacy and retention line

This section is what separates a defensible deployment from a liability. Decide all five before switching anything on.

What you log. Destination, decision, rule matched, user, and timestamp. Full request and response bodies should not be your default. They are both a storage problem and, more importantly, the thing that turns a security log into a surveillance archive.
How long you keep it. Pick a period tied to your actual investigation window, and enforce deletion automatically. "Indefinitely" is a decision too, and a bad one.
Who can read it. A named, small group, with access logged. Inspection logs are among the most sensitive data your organization holds.
What people are told. Employees should know the practice exists, which categories are bypassed, and who to ask. In several jurisdictions this notice is a legal requirement rather than a courtesy.
What happens on a request. Someone will eventually ask what you hold about them. Know the answer in advance.

Get these written down and approved by whoever owns employment policy, not just by the security team. Inspection deployed without that agreement tends to be switched off loudly rather than quietly.

What to do next

For the architecture behind this, including why SOCKS5 and CONNECT tunnelling see different things, read Proxies Explained.
For a workbench tool to inspect your own application's traffic, rather than a fleet-wide gateway, see Top 5 Intercepting Proxy Tools for 2026.
If your goal is bounding what an automated workload can reach rather than reading what humans send, Egress Control for AI Agents is the closer fit.

Key takeaways

If you cannot supply managed devices, a written bypass list, and a defensible retention policy, do not deploy TLS inspection. A partial version is a broken control, not a smaller one.
Mechanically, inspection is a man-in-the-middle attack. Consent and trust-store control are the only things that separate it from one, and both are governance facts rather than technical ones.
If your requirement is blocking categories or logging sites visited, you do not need inspection at all. Destination-based policy does that without decrypting anything.
An explicit forward proxy that terminates TLS is unaffected by Encrypted Client Hello. Policy built on SNI inspection at a firewall is the thing that needs migrating.
Do not default to logging full request bodies. That is what turns a security log into a surveillance archive, and it is a storage problem on top.
Get the retention and notice policy approved by whoever owns employment policy, not only by the security team.

Frequently asked questions

Is TLS inspection legal?: It depends on jurisdiction and on the notice given to the people whose traffic is read. In several jurisdictions employees must be informed, and certain categories such as health and banking may not be readable at all. Treat it as a policy question with a technical implementation, get sign-off from whoever owns employment policy, and do not rely on a general answer found online.
Why does TLS inspection break some mobile apps?: Certificate pinning. The application has the expected server certificate or public key built in and rejects anything else, including a certificate signed by your organization's root authority. It does not fall back to an inspectable connection, it fails. Banking and payment apps commonly pin, so they have to be bypassed by destination rather than inspected.
Can I inspect traffic on personal or contractor devices?: No. Inspection depends entirely on installing your root certificate authority on the device, and you cannot do that on hardware you do not control. There is no partial version of the control. Route those devices through destination-based policy instead, or require a managed device for access to the systems that need inspection.
Does Encrypted Client Hello end TLS inspection?: No. ECH, published as RFC 9849 in March 2026, encrypts the server name in the handshake and removes a metadata signal that firewalls rely on. It does not affect an explicit proxy that terminates TLS on a managed device. Measured adoption also remains well under one percent of connections, so treat it as planned migration work.
What should a TLS inspection deployment log?: Destination, decision, rule matched, user, and timestamp are enough for most investigations. Full request and response bodies should not be the default, because they create a storage burden and turn a security log into a surveillance archive. Set an automatic deletion period tied to your real investigation window.