The U.S. National Security Agency (NSA) has published an advisory to provide information on possible mitigations for risks associated with Transport Layer Security Inspection (TLSI).
Also known as TLS break and inspect, TLSI is a mechanism that allows for the inspection of encrypted traffic within a network and involves the decryption of that traffic, inspection of contents, and re-encryption.
TLSI is usually performed by a proxy device to expose the underlying plaintext of a TLS session and allow firewalls, and intrusion detection/prevention systems (IDS/IPS) to detect indicators of threat or compromise. Legacy Secure Sockets Layer (SSL) traffic is also inspected.
According to the NSA’s advisory (PDF), one of the risks associated with TLSI is improper control and external processing of decrypted traffic when in a forward proxy or near the enterprise boundary.
A forward proxy is a device that intercepts requests from internal network clients and forwards them to external servers. It also receives responses from those servers and sends them to internal network clients.
In a forward proxy, the TLSI mechanism manages forward proxy traffic flows, establishes TLS sessions, and issues trusted certificates. Thus, it can protect enterprise clients from the high risk environment outside the forward proxy.
However, the forward proxy could misroute the traffic, thus exposing it to unauthorized or weakly protected networks, the NSA advisory says.
Deploying firewalls and monitoring network traffic flow can protect the TLSI implementation from potential exploits, while implementing analytics on the logs ensures the system is operating as expected. Moreover, these mitigations can also detect abuse by security admins and misrouted traffic.
TLSI occurs in real-time and replaces the end-to-end TLS session with a “TLS chain” that consists of two independently negotiated TLS connections: one with the internal network client and another with the external server. The TLS traffic, however, flows as if there is a single connection.
The TLS chaining could result in a TLS protection downgrade, as the TLS version or cipher suites could differ from one connection to the other. This, the NSA points out, could lead to a passive exploitation of the session or of vulnerabilities in the weaker TLS versions or cipher suites.
To prevent that, admins should properly configure TLS security settings, including version, cipher suites, and certificates, and disable weak TLS versions and cipher suites on the server-side and prevent clients from using them.
Where outdated applications that require weak TLS versions and cipher suites are used, admins should constrain that usage so that they are negotiated for exempted clients only.
Applying certificate pinning should help detect unauthorized changes to TLS certificates received from external servers — this might be an indicator of man-in-the-middle attacks against the proxy — and certificate transparency can be used to report unauthorized certificates to the owners of the external servers.
TLSI forward proxy devices also include a certification authority (CA) function to issue and sign new certificates that represent the external servers to the TLS client — the client is configured to trust the CA.
This mechanism, however, can be abused to issue unauthorized certificates trusted by the TLS clients, which allows an attacker to sign malicious code and bypass host IDS/IPSs.
Protections include issuing the embedded CA’s signing certificate for TLS inspection purposes only, not using default or self-signed certificates, and monitoring traffic for unexpectedly issued certificates.
Certificate revocation services should be enabled for certificates cached by the TLSI system, so that any unauthorized certificates can be easily revoked. The embedded CA should be configured to issue only TLS server authentication certificates.
“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,” the advisory reads.
Adversaries, the NSA points out, could focus on exploiting only the device where potential traffic of interest is decrypted. To mitigate this risk, admins should set a policy to enforce decryption and inspection of traffic only as authorized, and to ensure that decrypted traffic is contained to an isolated segment of the network.
To prevent internal abuse from security administrators that manage the TLSI implementation, the principles of least privilege and separation of duties should be used. This ensures that only authorized admins have access to decrypted data, while others don’t. A separate auditor role should be used to detect policy modifications and other potential abuse.
The NSA also points out that, in the United States, enterprises operating TLSI capabilities are subject to privacy laws, policies, and regulations and that they should be aware of requirements and prevent unauthorized exposure of data.
To minimize risks associated with TLSI, the NSA notes, breaking and inspecting TLS traffic should only be conducted once within the network, as that is enough to detect encrypted traffic threats. Performing the inspection multiple times could complicate diagnosing network issues with TLS traffic.
“Also, multi-inspection further obscures certificates when trying to ascertain whether a server should be trusted. In this case, the “outermost” proxy makes the decisions on what server certificates or CAs should be trusted and is the only location where certificate pinning can be performed,” the advisory reads.
Related: Over 100,000 Fake Domains With Valid TLS Certificates Target Major Retailers
Related: Study Finds Rampant Sale of SSL/TLS Certificates on Dark Web
