What is the first thing that comes to your mind when you hear “NSA”?

I bet it would be something concerning privacy violations, but let’s stay away from that. We have a good reason to do so, because recently NSA has pushed out a TLSI advisory for security admins in need. 

It is packed with information about TLS chaining, forward proxies, and all misconfigurations admins can bump into, which is not a testament to their negligence, but evidence that TLSI products can cause more harm than good.

I’ll share my personal opinion about the whole topic right now. 

First of all, there are multiple ways of executing a successful man-in-the-middle attack without buying NIAP-approved products.

TLSI is essentially a risky trade-off, where you get slightly more insight into what’s leaving and entering your network under the impression that it will protect you from critical data loss or compromise. From my point of view, with TLSI you get a single point of failure where all traffic is up for grabs. More examples needed?

When a company launches TLS break and inspect “from the box,'' they essentially open Pandora’s box, signing up for more trouble than TLSI can resolve.

• Default or self-signed certificates can be used to abuse the embedded CA.
• Malicious code can bypass host IDS/IPSs.
• Malicious services can impersonate legitimate services.

On top of that, any person having access to TLSI has access to all the information, passwords to external and internal accounts, etc. You can imagine how that can backfire... Capital One example is still fresh in the memory.

For my taste, NSA advisory gives us obvious recommendations, like using a trusted CA, monitoring enterprise traffic for unexpected and unauthorized certificates or stating something painfully obvious:

Yeah, that’s the plan.

Me just throwing stones at NSA is not going to make things better, but I can tell you something less obvious. Сons of implementing TLSI can outweigh the pros, if configuration issues are in place. Understanding all the revised challenges, we should immediately think of ways to maintain actual data security during transmission.

First of all, we should not rely solely on SSL/TLS as a tool for data protection, as it ensures the security of the channel, not data coming through it. Think of it this way… TLS is shoes you better wear if you don’t want to get a cold. 

Could you get a cold with your shoes on? Sure. 

SSL/TLS is a must, but the data encapsulated in the channel also has to be encrypted. Users should control encryption and prevent unauthorized access to data at any point, so use the services that would keep sensitive information safe even after TLS stripping. That’s one of the examples I kept in mind when designing email security service StealthMail.

Of course, StealthMail is not a cure-all type of solution. Secure email gateways, rights management services, data loss prevention software, antiviruses, spam filters are still essential, but StealthMail can offer you control over encryption keys and data. 

So, TLSI or no TLSI? No matter how many arguments we have about the topic, the only thing that matters is the security of your internal services.