The essentials in 30 seconds
- Without decryption, network DLP only sees a domain and a volume. The content escapes it.
- Exclusions, pinned applications, exempted categories and traffic that bypasses the proxy create silent blind spots.
- To measure your coverage, we send decoy files down each path and look at what the DLP does with them.
Take a typical scenario: every attempt to exfiltrate decoy files to GitHub (in this case through GitHub Gist) succeeds. 100%. No exotic vulnerability involved. GitHub is a legitimate destination for development teams, so it is often excluded from TLS inspection, and git push flows are not covered by any DLP rule either. As a result, the proxy only sees encrypted traffic to github.com on port 443, or SSH on port 22, which it never decrypts anyway.
TLS inspection allows a network DLP to read the content of outbound HTTPS flows and apply its rules to them. We rarely find its blind spots in a technical flaw. They come from your exclusion lists, from applications that refuse decryption, from website categories deliberately left uninspected and from workstations that bypass the proxy.
Why TLS inspection does not see everything
Almost all outbound web traffic is encrypted. Without decryption, your network DLP sees a domain name (via SNI or DNS resolution), a volume and a destination. Not the content. With Encrypted Client Hello (ECH), a TLS 1.3 extension specified separately by the IETF that Chrome and Firefox have enabled since 2023, even the SNI can disappear. That is why your teams enable inspection on the proxy, the firewall or the SSE gateway. MITRE ATT&CK classifies sending data over an encrypted channel under T1048.002.
The catch is that TLS inspection is a permanent compromise. Every time an application breaks, the legal department gets worried or a director complains about slowness on a Monday morning, an exception gets added. Accumulated over 3 years, these exceptions add up to a tunnel. And an attacker, or an employee in a hurry, only needs one tunnel.
Diagram · what the DLP sees
The four families of blind spots
1. Exclusion lists that have grown
Your exclusions fall into 3 drawers (domain, category, IP address or range). The classic drifts:
- Overly broad wildcards: excluding the whole of *.example.com for a single subdomain that caused trouble. Everything hosted beneath it (storage, sharing, APIs) then leaves without your DLP reading anything.
- Hosting and CDN exclusions: an exception placed on shared infrastructure, or on the Microsoft 365 ranges the vendor recommends not inspecting, also covers content you never had in mind.
- Temporary exceptions that became permanent: added on a Friday evening during a production incident 2 years ago, never removed, with no owner and no expiry date.
- Per-user or per-group exclusions: senior management, development teams, contractors. These are often the teams with access to the most sensitive data.
2. Applications with certificate pinning
Some applications check that they are talking to the expected certificate (certificate pinning). Your proxy presents its own, the application rejects it, and your network team adds it to the bypass list. This often happens with sync clients, video conferencing, update agents, mobile apps and some development tools, including the git client when it ignores your internal certificate authority.
3. Categories deliberately left uninspected
Health, online banking, public services: not decrypting a medical appointment booked on Doctolib or a bank statement reflects genuine privacy concerns for your employees, and is often covered by an agreement with employee representatives. Still, ask yourself 2 questions:
- Is your vendor’s categorisation reliable for niche sites, where a miscategorised file-sharing service can end up exempted?
- Do you have a compensating control (volume limits, an alert on any upload over 50 MB to an exempted category, endpoint control)?
4. Traffic that never goes through inspection
Points to check: your mobile workstations off VPN or with split tunnelling, your servers and cloud workloads, on Azure or elsewhere, that go straight out to the Internet, protocols that escape the explicit proxy (QUIC and HTTP/3 over UDP 443, RFC 9000 and 9114, if your equipment does not handle them), and browser-side encrypted DNS resolution that short-circuits your DNS controls. That last point is covered in our article on DNS exfiltration.
Summary table: blind spot, symptom, compensating control
| Blind spot | What the DLP sees | Possible compensating control |
|---|---|---|
| Overly broad domain exclusion | Domain and volume, not the content | Narrow it to the exact subdomain, with an owner and an expiry date |
| Pinned application on bypass | Nothing at content level | Endpoint DLP, restriction to corporate accounts, blocking |
| Exempted category (privacy) | Category and volume | Volume thresholds, upload alerts, endpoint control |
| Mobile workstation outside the tunnel | Nothing | Always-on SSE client, endpoint DLP |
| QUIC not supported | Depending on the equipment: nothing | Block UDP 443 to force fallback to TCP 443, which is inspected |
How to check your real coverage
Review the configuration, of course: it describes the intent. To see what actually happens on the network, we work in 5 steps.
- Inventory the exceptions. Export all your no-decryption rules (domains, categories, IPs, users, applications). For each one, note who requested it, why and since when. An exception with no owner goes to the top of the list.
- Build detectable synthetic data. Decoy documents that are certain to trigger your DLP rules (fake social security numbers in a valid format, fake 27-character IBANs, classification markers). The method is detailed in testing exfiltration in production with synthetic data.
- Replay the upload on every path. Same decoy file, same reference workstation on Windows or Linux, first to an inspected destination (the control test), then to one destination per exception family. Within our scope, that means HTTPS and HTTP uploads, GitHub Gist, Google Drive and paste sites such as DPaste; for exempted categories, your team applies the same principle. Vary your profiles: office workstation, mobile workstation, standard account, account in an exempted group.
- Compare 3 results per scenario. Was the session decrypted? Did the DLP rule fire? Did your SOC receive an actionable alert? A “yes” to the first question and a “no” to the third is common, and just as much of a problem. On the Enforcis side, upcoming versions will bring multi-level reporting (leadership, CISO, operations), with MITRE ATT&CK mappings and, where the correspondence is established, MITRE D3FEND, as well as SIEM integrations.
- Replay after every change. A proxy update, a new exception, an SSE migration: each of these changes shifts coverage. A one-off test gives you the state on one day. Replayed regularly, it shows you whether coverage is degrading.
A concrete scenario
Back to the GitHub case from the start. Block GitHub? Wrong answer: your developers need it, and they will find a workaround. Instead, distinguish the company’s GitHub space from an arbitrary third-party repository. Your GitHub organisation stays authorised, with a compensating measure such as MFA, at the CISO’s discretion. A third-party repository, or a public gist created with a personal account, should never be reachable. On the network side, that means restricting the decryption exclusion to the strictly necessary uses and compensating with an endpoint control on git push flows. We then replay the same decoy file to check that the fix holds on this path. MITRE ATT&CK classifies this path under T1567.001, Exfiltration to Code Repository.
Next step
What does your TLS inspection really see?
A 30-minute demo: a full campaign across the 8 channels we test, on our demo environment. The POC shows, on site, how the solution behaves in your environment, on one simple scenario in a synthetic environment. What actually leaves through your channels is what the pilot shows you.
Quick checklist for the CISO
- Each of your decryption exceptions has an owner, a justification and a review date, every 6 months for example.
- Every bypassed application has an identified compensating control.
- How your equipment handles QUIC (UDP 443) is known and tested.
- git push flows to repositories outside your organisation are blocked or alerted.
- An active test checks, at least after every major change, that your DLP rules fire on HTTPS traffic.
The overall framework is on our reference page, data exfiltration testing.
FAQ
Should you decrypt 100% of HTTPS traffic?
No. It is unrealistic, and sometimes at odds with your obligations towards your employees. What matters is knowing what is not decrypted and compensating for each gap with another control.
Is TLS inspection enough for effective DLP?
It is necessary for your network DLP. Yet it covers neither pinned applications, nor workstations outside the tunnel, nor SSH on port 22. Keep endpoint DLP and the CASB alongside it.
How can you tell whether a session was decrypted?
Proxy or gateway logs generally record the decryption action per session. Cross-check them with DLP logs during a test: a session with no trace of inspection, to a destination that is supposed to be inspected, shows you a blind spot.
Should you block GitHub?
No. Distinguish your GitHub organisation, authorised with a compensating measure such as MFA at the CISO’s discretion, from an arbitrary third-party repository, which should never be reachable. We then check with a test that this boundary holds.