Stop Breaking TLS

Enterprise TLS interception experiences

• Multiple anecdotes of corporate MITM: internal CAs pushed to endpoints, Zscaler/Netskope boxes in the path, and half‑baked deployments causing widespread TLS errors.
• Developers report constant friction: broken tools (Git, Maven, npm, JVM websockets), weird cert chains, and obscure failures (e.g. non‑HTTP TLS killed by middleboxes).
• Common outcome: people normalize curl -k / “verify=false”, adding insecure hacks to runbooks and code, undermining TLS as a whole.

Security benefits vs harms

• Pro‑inspection side: claims real wins catching malware C2, credential phishing, data exfiltration, and users pasting sensitive data into SaaS/LLMs.
• TLS inspection enables fine‑grained DLP rules (e.g. blocking uploads matching customer IDs or card numbers) and lets regulated orgs argue they “did everything they could”.
• Critics argue there’s little published evidence on net effectiveness and that engineering time lost working around breakage is enormous.

Legal and privacy considerations

• EU/GDPR angle: handling employee traffic that includes personal or health data can trigger strong privacy protections and data‑minimization duties, even on company devices.
• Consensus: legality is about “spying on employees” end‑to‑end, not about TLS mechanics; antivirus‑style monitoring may be justifiable, bulk logging of private use likely not.
• Some argue work networks need strict controls (e.g. to stop Netflix saturating small links or kids accessing inappropriate sites); others see this as overreach or solvable by simpler policies.

Operational and technical complexity

• TLS interception centralizes risk: one internal CA becomes a single high‑value target that must be run like a real CA (HSMs, ceremonies, rotation).
• Fragmented trust stores (OS vs browser vs language runtimes) make rollout brittle; Linux/Posix ecosystems highlighted as especially painful.
• Security appliances themselves often have poor TLS implementations and CVEs, creating new vulnerabilities.

Cloudflare and broader trust model debates

• Side debate: is using Cloudflare (or similar) for public sites morally equivalent to corporate MITM?
  • One side: it’s effectively a massive global middlebox for critical services, under US jurisdiction.
  • Other side: that’s a chosen reverse proxy for specific endpoints, not blanket interception of all internal traffic.

Alternatives and mitigations

• Suggested alternatives: explicit HTTP proxies instead of transparent MITM, stronger endpoint security/EDR, DNS/IP blocking, bandwidth shaping, device policies, and better CT log use.
• Several argue TLS inspection should be limited in scope, only used by mature, highly regulated orgs, and never implemented “half‑assed.”