when it comes to protecting the privacy and integrity of data in transit. Your organization doesn’t want a malicious outsider to intercept your customers’ financial data when they buy things from your eCommerce site. Or even if the data being transferred is innocuous, a man-in-the-middle attack can be a means for a cyber attacker to acquire unauthorized access to endpoints and servers. That’s why we try to use the best TLS technologies we can, implemented as effectively as we can.
But encryption can also be a tool for the bad guys. Malware in ciphertext may evade antivirus detection. Encrypted network sessions may let unauthorized traffic slip past your firewalls, exposing your networks to tremendous risk. So, organizations need a way to inspect TLS packets to ensure that their contents are authorized and safe. Enter TLS inspection, or TLSI for short.
Typically, TLSI is conducted with proxy nodes. Forward proxies inspect TLS packets being sent from internal networks to external networks, usually the Internet. Internal proxies can inspect traffic within an internal network, such as a WAN or LAN. A proxy has its own machine identities and it can use them to decrypt TLS packets so that firewalls, intrusion detection systems, and intrusion prevention systems have cleartext they can examine. Proxies can then re-encrypt packets with the use of new certificates as needed in the flow of network traffic. When a TLS session has TLSI at some point, it becomes a “TLS chain” of two independently negotiated TLS connections.
The National Security Agency recently released a warning about the risks of TLSI. The NSA sees the need for TLSI, but they warn about TLSI vulnerabilities and suggest ways that they can be mitigated. First, there’s a warning about forward proxies:
“A risk associated with TLSI within a forward proxy is improper control and external processing of the decrypted traffic at or near the enterprise boundary. A forward proxy that forwards decrypted traffic to external inspection devices could misroute the traffic and result in exposing sensitive traffic to unauthorized or weakly protected networks.”
They recommend implementing more firewalls on all network interfaces to the forward proxy, and to monitor the associated network traffic effectively.
As I mentioned, when TLSI is introduced into a TLS session, it becomes a TLS chain. The NSA warns that the complications associated with those chains may introduce new vulnerabilities:
“While there are two separate connections, TLS traffic flows as if there were a single connection. This TLS chaining risks a potential downgrade of TLS protection from what was accepted by the client. The TLS version or cipher suites used in one independently negotiated connection can be weaker than those negotiated for the second connection. This could result in passive exploitation of the session, or exploitation of vulnerabilities associated with weaker TLS versions or cipher suites.”
So great care must be taken when implementing forward proxies to assure that TLS versions, cipher suites, and certificates are compatible, and the most secure options are used. Clients such as web browsers must also be prevented from forcing the usage of weak TLS versions and cipher suites. And of course, unexpected changes to TLS certificates received from external servers may indicate a man-in-the-middle attack. Watch out!
Certificate authorities help to assure the integrity and authenticity of TLS certificates. Because TLSI requires that new certificates are issued within a TLS session, certificate authorities can be another vulnerability.
“TLSI forward proxy devices incorporate a certification authority (CA) function that creates and signs new certificates that represent the external servers to the client: the CA embedded in the forward proxy issues a certificate indicating the properties of the requested external server’s certificate. The TLSI system uses this certificate during the processing of TLS traffic in the connection between the TLS clients and forward proxy. The TLS clients are configured to trust the CA. The primary risk involved with TLSI’s embedded CA is the potential abuse of the CA to issue unauthorized certificates trusted by the TLS clients. Abuse of a trusted CA can allow an adversary to sign malicious code to bypass host IDS/IPSs or to deploy malicious services that impersonate legitimate enterprise services to the hosts.”
So, choose your CAs carefully and guard them thoroughly!
“Configure TLS clients to trust the external CA so they only trust the certificates the TLSI system issued for TLS server authentication. Issue the embedded CA with a certificate that has name constraints to reinforce limitations of the inspection authorization and prevent impersonation of enterprise services.”
There’s also another major vulnerability. TLSI makes ciphertext cleartext within an area of the TLS chain. That becomes a lucrative node for cyber attackers to conduct a man-in-the-middle attack! This can be mitigated by implementing a security policy to enforce that traffic is decrypted and inspected only as authorized and ensuring that decrypted traffic is contained in an out-of-band, isolated segment of the network.
And we mustn’t forget the risk of insider attacks to the cleartext within a TLSI implementation. Some of the usual measures like the principle of least privilege and separation of duties must apply to all people who have access to the TLSI within your organization’s networks.
TLSI can make the work of network security devices much easier. But we must heed the NSA’s warnings to make sure that the vulnerabilities they can introduce are mitigated.
The NSA’s warnings about TLSI apply to connections to external networks with forward proxies. But TLSI can also be implemented within an internal network. TLSI should be safer within an internal network because your organization can control it in ways you cannot control the Internet and other external networks. Either way, in any TLS system, proper machine identity management is a must. TLSI means your networks will need even more certificates than they would otherwise. You must have full visibility into all of your machine identities and automate as much as possible.