SSL inspection, explained: why doing it on-device beats the cloud-proxy model

Somewhere north of 95% of internet traffic is now encrypted. That's great for privacy against random observers. It's a problem for the security tools you actually pay for.

Without SSL inspection, your DLP can't see what's in an upload, your anti-malware can't see what's in a download, and your Cloud Application Control can't tell whether an OAuth flow is going to your corporate tenant or someone's personal one. Everything just looks like encrypted gibberish.

SSL inspection is how security tools get visibility back. This post is a plain-English walkthrough of what it is, how it works, the two main architectures, and why the architecture choice matters more than most buyers realize.

The short version

SSL inspection (also called TLS inspection, SSL decryption, or break-and-inspect) is the process by which a security control decrypts encrypted traffic, inspects the plaintext, and then re-encrypts it for onward delivery. The client and server still see an encrypted session. The security tool in the middle sees what's actually moving.

It's how a secure web gateway, DLP, or CASB can enforce policy on modern traffic.

How it works, under the hood

Three roles: the user's client (usually a browser), the destination server (some SaaS app), and the security control that sits in between.

1. The user's browser initiates a TLS connection to the destination.
2. The security control intercepts, presents its own certificate to the client, and establishes its own TLS connection with the real destination on the user's behalf.
3. Now the control has two encrypted tunnels: one to the client, one to the destination. It decrypts the traffic from one side, inspects it, applies policy, then re-encrypts for the other.
4. The client's OS has been pre-configured to trust the security control's root certificate. Without that, the browser would throw a loud certificate error on every page.

The work the control does in the middle is where the value is: matching URLs against categories, classifying file uploads for DLP, inspecting downloads for malware, logging the destination for visibility, and feeding data to CASB and CAC for tenant-level decisions.

It's sometimes called MITM (man-in-the-middle). The difference between SSL inspection and an attack is that you control the middle, and the root cert is on machines you manage.

The two architectures

Where the inspection happens is the thing that matters.

Cloud proxy inspection

Legacy cloud-based SWGs route every byte of user traffic up to a proxy server running in a data center somewhere. The proxy does the decrypt, inspect, re-encrypt, and then forwards. This was the dominant model from the mid-2010s to now.

The traffic flow:

User's laptop → Cloud proxy PoP → Internet → Destination → Cloud proxy PoP → User's laptop

Four hops. Two extra latency taxes. All traffic, regardless of sensitivity, passes through a third-party cloud.

On-device inspection

The inspection happens on the endpoint itself. The agent on the device does the decrypt, inspect, and re-encrypt locally. Traffic goes direct to its destination, no backhaul.

The traffic flow:

User's laptop (agent inspects) → Internet → Destination

One hop. No detour. The security control runs where the traffic originates.

This is the architecture dope.security uses for dope.SWG. We call it Fly Direct.

Why the architecture choice matters

Five practical consequences.

1. Latency

A cloud proxy adds a round trip to a regional PoP. For a user two time zones away from the nearest PoP, or on a slow network, or at the end of a congested link, the tax is 40 to 100 milliseconds per request. That adds up. Modern pages make 100 to 300 requests. An 80ms delay per request becomes a visibly slower web.

On-device inspection adds microseconds, not milliseconds. The inspection happens in-process, before the packet ever hits the wire.

2. Privacy and data residency

When a cloud proxy inspects, every employee's traffic passes through the provider's infrastructure. That includes personal banking, medical portals, tax filings, and everything else people do on work devices. The provider is in the trust chain whether or not you intended them to be.

On-device inspection keeps the plaintext local. Traffic flies direct, and the only party that ever sees the decrypted content is the agent running on the user's own laptop.

For data residency requirements, this matters. You're not promising your regulator that traffic stays in-region because your vendor said so. It never left the user's device.

3. Blast radius

Cloud proxy outages take down the whole architecture at once. Every user, globally, loses inspected internet. A fix-forward deploy problem becomes a workforce productivity event.

On-device inspection runs independently per endpoint. If the cloud console is unreachable, dope.endpoint falls back to cached policies and keeps protecting the user. The blast radius is one device, not 50,000.

4. Geography

Cloud proxy providers have PoPs in specific regions. Users outside the PoP footprint either get a long-haul experience or don't get inspected at all.

For China specifically, most cloud SWGs backhaul through the Great Firewall, which produces unpredictable failures and performance. On-device inspection doesn't depend on reaching a foreign data center, so users in China get the same security and experience as users in London.

5. Cost

Cloud proxy infrastructure has to scale with total user traffic. The bill grows with bandwidth. On-device inspection shifts compute to endpoints you already own. Cost scales with seats, not packets.

The honest downsides of on-device inspection

To be fair, here are the things on-device SSL inspection has to get right.

Cert management. The agent generates a root cert, and that cert has to be trusted by the OS, the browser, and any pinned-certificate apps on the machine. Deployment via MDM handles this at scale. It's solved, but it's a detail to plan.

Pinned-cert apps. Some apps (banking apps, some corporate-managed tools) pin to specific certs and refuse to trust a MITM'd one. The agent has to maintain a bypass list for those.

OS edge cases. New versions of macOS and Windows occasionally change how network extensions or traffic interception work. The agent vendor has to keep up.

dope.endpoint is a native agent for Mac and Windows that ships through the MDM channel you already use. Root trust deploys with the agent, and bypass handling for pinned-cert apps is supported at the policy layer.

When to bypass SSL inspection (and how to do it safely)

Not every session should be inspected. Some should be passed through.

Banking and financial portals. Legal exposure if decrypted. Bypass by category.

Healthcare patient portals. HIPAA considerations for the employee as a patient. Bypass by category or URL.

Corporate PKI and internal apps. Already encrypted end-to-end with your own CA. No value added from a second inspection.

Specific third-party integrations. Sometimes a partner's API requires cert pinning for legitimate security reasons.

The pattern is the same everywhere: bypass by URL category or domain, log the bypass, make sure you're not excluding more than you need.

What a modern implementation actually needs

If you're evaluating SWGs and DLP tools on their SSL inspection story, ask for:

• On-device inspection with a native agent for Mac and Windows.
• Root cert distribution through MDM, not manual install.
• Bypass rules for pinned-cert apps and sensitive categories, working out of the box.
• Fallback mode that keeps protecting when the cloud console is unreachable.
• A trust chain you can audit and explain to your privacy team.
• Performance numbers. On-device should be near-zero overhead; cloud proxy should be disclosed.

Where dope.security fits

dope.SWG inspects SSL traffic on-device through dope.endpoint, under the Fly Direct philosophy. Traffic goes direct to destination. Plaintext stays local. Policies push in seconds from dope.console. The agent falls back to cached policies during console outages.

That's the architecture. It's how we built SSL inspection that doesn't punish users with latency or surrender their plaintext to a third-party cloud.

‍