Rant ahead: I hate TLS “inspection” software and I wish we as an industry would collectively do away with it. Shame! Stop and stop pretending this is some huge security benefit. Whenever I encounter it, in whatever form it is, it’s a huge headache that makes everyone’s life worse and provides almost zero tangible benefits as far as I’m concerned.
For those blissfully unaware, this is a class of “security” software or tools that lets organizations monitor all encrypted traffic. It does this by inserting itself in the middle of the traffic, removing the encryption so it can inspect it and then re-signing it with its certificate. If this sounds familiar, it’s because it’s a widely known class of attack – the Man in the Middle attack. Nice thing, we’re deploying virtually the exact attack vector that TLS was designed to prevent, but labeling it “security”.
First, it weakens one of the most important protocols of the modern Internet because it deliberately breaks all the guarantees that TLS encryption is supposed to offer. If the MITM certificate is installed everywhere, your company can intercept and monitor everything you do. Consider the implications of this – confidential messages to HR, medical information, insider trading information, your banking sessions – would you feel happy having to BCC every email to your IT department? Will you print out your therapy notes and pin them to a kitchen notice board?
But even ignoring the philosophical arguments about privacy and trust, I’d argue that it actively protects you. much worseConsider this – what is the probability that the private keys of every certificate authority on the Internet will be compromised simultaneously? I bet it’s roughly the statistics equivalent of the Planck length level of probability,
On the other hand, what are the chances that your company’s MITM private key will be compromised by an attacker? Even if you trust your IT team and vendor completely (and if you do, you clearly haven’t been paying attention to any tech news for the past few decades), you have to admit that the possibility is very high. And depending on the vendor or technology stack involved, it could be much higher. A disgruntled employee, an unpatched vulnerability, a phishing email to the right administrator and choo-choo, it’s all aboard the fail train. Now an attacker can have the keys to your entire kingdom.
Then there are the practicalities of it. It’s just a big hassle. Different operating systems expect certificates in different formats (PEM? DER? PFX? P7B?) that are installed in different places with different tooling to manage it. update-ca-certificates versus update-ca-trust This is just the tip of the iceberg – and that’s just the OS level. Then you have the language runtime (Java keystore anyone?) and the applications themselves that need to be configured.
And the problem becomes even more complex with modern cloud-native apps. In a Kubernetes cluster, as well as handling the task of updating node VM images and container runtimes, you will have dozens, if not hundreds, of different base images, each with its own standards. Alpine uses a different certificate path than Ubuntu. Your node app expects them somewhere else entirely. The different CRDs or Helm charts you are using may or may not support custom CA bundles, and if they do there is no agreed standard.
Now I’m not saying that a problem is hard so we should give up, but even if the benefits are worth it, the simple fact is that even with the best tooling and automation, you are Guarantee To miss something. Whether it’s some obscure tool that has a custom keystore and non-standard tooling, a quick “one off” command in an ephemeral container, some app that uses certificate pinning or an old Switch firmware that doesn’t even support custom certificate bundles, Some? Will slip through the cracks. And when that happens, guess what happens?
Which leads me to my biggest gripe: It normalizes bad security practices. Given that you will never have 100% coverage of your CA certificate installation – especially across your technical teams who may be using different devices and platforms – you will find developers and system admins becoming accustomed to TLS errors. Instead of treating each one as an anomaly and something to be investigated, you just get used to running --insecure Or curl -k Because you just need to get the job done. Turning off certificate verification becomes a routine troubleshooting step. “Oh, it’s probably just the corporate proxy again” becomes the default response to any TLS error. You’ve just trained your entire technical staff to ignore one of the most important security warnings on the Internet!
And don’t even get me started on the performance and availability implications. Now all your traffic has to be decrypted and re-encrypted by your magic box. Hope you sized that device right! Hopefully this won’t create a single point of failure! Hope it supports all the latest TLS versions and cipher suites!
There are several ways to protect yourself that are not only less invasive but often More Effective because they are designed for how modern infrastructure actually works. Anomaly detection, Zero Trust network architecture, EDR, NetFlow analysis… you don’t need to create single points of failure, and you can actually work with modern cloud-native infrastructure instead of fighting it. Also, you know, there’s this AI thing that’s really quite useful in analyzing metadata and detecting strange behavior patterns.
In my experience: TLS inspection MITM is a huge administrative burden, it normalizes bad practice, it creates bottlenecks and availability risks, and actively degrades your security posture.
Just turn it off already.
<a href