Part 2: Cloudflare Zero Trust - TLS Inspection

In Part 1, we enabled TLS inspection to get HTTP policies working against HTTPS traffic — that’s how we blocked social media sites on port 443. We got it working, but I didn’t really explain what TLS inspection is actually doing under the hood. Let’s fix that.

TLS inspection is essentially a sanctioned man-in-the-middle. When your device initiates an HTTPS connection, Cloudflare Gateway intercepts it, terminates the TLS session, decrypts the traffic, inspects it, and re-encrypts before forwarding to the destination. Same thing in reverse on the way back. The Cloudflare root CA certificate we installed on the client device is what makes this work without your browser throwing certificate errors on every page.

Blocking social media sites was a decent demo, but honestly, you don’t even need TLS inspection for that — a DNS policy can do the same job. The real value of TLS inspection is that Gateway can now see the full HTTP request and response — headers, body, uploaded files, form data, everything. That’s what unlocks features like Data Loss Prevention and malware scanning, which are completely blind without it.

That’s what this post is about.

Why is it required?

Think about this — an employee is working with a spreadsheet containing customer social security numbers. They need to access it from home later, so they upload it to their personal Google Drive. No malicious intent, just convenience. Without TLS inspection, Gateway sees a connection going to drive.google.com over HTTPS and that’s it. It has no idea what’s inside that upload. The SSNs leave your network, sitting on a personal account you have zero control over.

Now flip the scenario. A corporate laptop gets compromised. The malware is smart enough to exfiltrate data over HTTPS — maybe to a cloud storage endpoint, maybe to a C2 server disguised as a legitimate service. Again, without TLS inspection, Gateway sees encrypted traffic going to what looks like a normal HTTPS destination. It can’t inspect the payload, can’t scan for sensitive data patterns, can’t flag the exfiltration. The data is gone.

Both problems — accidental and malicious — have the same root cause. Encrypted traffic is opaque to your security stack unless you break it open and look inside. TLS inspection gives you that visibility. And once you have it, you can layer on DLP to catch the SSNs before they leave, or scan for malware signatures in file uploads. Without it, you’re just watching encrypted blobs fly past and hoping for the best.

Prerequisites

Before we get into DLP, let’s make sure the basics from Part 1 are still in place. TLS inspection should be turned on and the Cloudflare root CA certificate should be properly configured on your device.

If either of these isn’t set up, go back to Part 1 — nothing that follows will work without them.

Implementation

Let’s see this in action. The plan is simple — create a file with US Social Security Numbers, try uploading it to Google Drive, and see if Cloudflare catches it.

First, I created an HTTP firewall policy that blocks any traffic matching the predefined SSN DLP profile (Social Security, Insurance, Tax, and Identifier Numbers). Cloudflare does not allow to create DLP profiles in the free tier and hence have to use the predefined profile.

With the policy in place, I tried uploading the file to Google Drive. It didn’t go through, the download was stuck forever!

And sure enough, Cloudflare’s Gateway logs confirm the block.

That’s DLP doing its job. The file never made it to Google Drive. Gateway decrypted the upload via TLS inspection, scanned the contents against the SSN detection profile, matched it, and killed the request. Without TLS inspection enabled, this upload would have gone through silently — Gateway wouldn’t have been able to peek inside the encrypted payload to detect the SSNs.

A word of caution — false positives

This is where things get annoying. DLP with predefined profiles is not surgical. It’s regex-based pattern matching, and anything that looks like an SSN structurally can trigger a block.

I found this out the hard way. With the SSN DLP policy active, Cloudflare blocked me from accessing my own blog. Not a shady site, not a file upload — my Medium blog. The false positive rate was significant enough to be disruptive.

Deploy and test the policy first in a dev/staging environment. Understand what’s getting flagged before you start blocking traffic — otherwise you’ll be fielding helpdesk tickets all day from people who can’t access legitimate sites 😥😉

Conclusion

In this post, we took TLS inspection beyond just blocking social media sites. We used it to power DLP — detecting and blocking a file containing US Social Security Numbers before it could reach Google Drive. The upload never made it out. Gateway decrypted the traffic, scanned the payload, matched the SSN pattern, and killed the request. That’s the real payoff of TLS inspection.

In an enterprise environment, this isn’t optional. Between employees moving data to personal storage and compromised endpoints trying to exfiltrate to C2 servers, encrypted traffic is the primary channel for data leaving your network. If your security stack can’t look inside it, you’re operating blind. TLS inspection is the foundation — DLP, malware scanning, everything else sits on top of it.