The list of organizations warning about the dangers of decrypting and inspecting HTTPS traffic just got longer.
The National Security Administration (NSA) published a cyber advisory last week describing the risks of using what it calls ‘Transport Layer Security Inspection’ (TLSI).
“Devices that break and inspect the TLS traffic may become high priority targets for exploitation and introduce additional risks into an enterprise network,” according to the advisory.
HTTP Inspection: The Simple Days
Years ago, it was easier to filter web traffic. Most traffic was sent via HTTP, which shows data in plaintext.
Any third party that intercepted the traffic could see the data as easily as one opens a text document.
This made it easy for security proxies (like an IDS/IPS firewall) to inspect the traffic, block the bad, and allow the good.
But this also made it easy for attackers. After intercepting traffic, they could easily read passwords, account numbers, and anything else sent on the web.
In time, people learned that HTTP is not secure, especially for critical services such as banking.
HTTPS Adoption Skyrockets
HTTPS is a secure, encrypted version of HTTP. It dates back to the mid-1990s when Netscape invented the (now deprecated) SSL protocol. Today, TLS is the main family of protocols used for HTTPS.
HTTPS is almost identical to HTTP, except most of the information is encrypted. That means any third party intercepting the traffic will receive little more than useless, garbled text (assuming proper configuration).
That’s true whether the third party is a criminal or a network security device like an IDS/IPS firewall.
HTTPS adoption dawdled for nearly a decade before skyrocketing around 2015. Now most web traffic is encrypted.
This is great news for security – but it presents a challenge to many network security products.
Breaking Encryption to Inspect Traffic
As HTTPS grew, more cyber attackers began using it to evade detection.
Today, to combat this, many security vendors offer features called HTTPS inspection, HTTPS web filtering, TLS filtering, and similar names.
The NSA calls it Transport Layer Security Inspection (TLSI) or TLS break and inspect.
The feature is found in many UTM firewall and antivirus products.
Here’s how it works:
- All HTTPS traffic is intercepted by a service (via client-side software or a network device).
- The service terminates and decrypts the HTTPS session.
- The service inspects the data (now in plaintext). If a threat is found, the connection is blocked.
- If the connection is allowed, the service creates a new HTTPS connection to the intended destination and sends the data.
This approach can detect and block threats hiding inside encrypted traffic – but it has many undesirable side effects.
Calls Against HTTPS Inspection
The NSA is not the first authority to warn of the dangers of TLS interception.
Last year, a team of researchers from Mozilla, Google, and UC Berkley published the results of an in-depth study that found “interception products as a class have a dramatically negative impact on connection security.”
Much of the impact is due to a failure of the security products to validate certificates and avoid vulnerable ciphers when establishing HTTPS connections.
In 2017, the Cyber Security and Infrastructure Security Agency (CISA) warned of similar risks in an alert titled, HTTPS Interception Weakens TLS Security. It characterized HTTPS inspection products as performing man-in-the-middle attacks on clients.
Risks of TLS Inspection (TLSI)
The NSA’s paper touches on the risk that TLSI products will downgrade connection security. However, it focuses more closely on the risks tied to entire concept of decrypting traffic for inspection.
What’s the big deal? Here are the risks caused by breaking TLS encryption, according the NSA:
#1. Improper control of decrypted traffic
Once traffic is decrypted, if it is sent to another host for inspection (such as an external server), there is a risk the traffic will be mishandled.
“[The proxy] could misroute the traffic and result in exposing sensitive traffic to unauthorized or weakly protected networks.”
#2. Downgraded TLS protection
A proxy that breaks encryption to inspect traffic must create a new HTTPS connection to forward traffic to the recipient. Unfortunately, the second half of this chain isn’t necessarily as strong as the first.
TLS Inspection products often allow weaker encryption on the second leg. This was thoroughly outlined in the joint research paper mentioned above.
“This could result in passive exploitation of the session, or exploitation of vulnerabilities associated with weaker TLS versions or cipher suites,” according to the NSA paper.
#3. Certificate Authority Compromise
To make all these HTTPS connections, TLSI products have an embedded certificate authority (CA) that creates and signs new certificates.
“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…This can allow an adversary to sign malicious code to bypass host IDS/IPSs or to deploy malicious services that impersonate legitimate [ones],” according to the NSA report.
#4. Single Point of Failure
The mere presence of decrypted traffic makes TLS inspection products a prime target for attackers.
“An adversary can focus their exploitation efforts on a single device where potential traffic of interest is decrypted, rather than try to exploit each location where the data is stored,” according to the NSA report.
#5. Insider Access to Decrypted Traffic
Malicious outsiders might not be the only ones attracted to a decryption bottleneck.
Malcontent employees and contractors who are authorized to manage the service may also be tempted.
“These authorized individuals could abuse their access to capture passwords and other sensitive data visible in the decrypted traffic,” according to the report.
AccessEnforcer UTM Firewall is Different
AccessEnforcer from Calyptix has HTTPS inspection – but it does not suffer from the problems described above – because it does not break encryption.
Most security products filter HTTPS traffic by breaking the encryption, inspecting the decrypted traffic, and forming a new TLS connection with the destination server.
AccessEnforcer never decrypts the traffic. Instead, we use a proprietary method of analyzing web server certificates to determine if connections are allowed.
This approach has two benefits:
- The browser’s encryption is not broken, which avoids the risks outlined in this post.
- The proxy device (AccessEnforcer) is not bogged down with a resource-intensive process (decrypting and encrypting traffic can be very demanding).
So you get an HTTPS web filter that blocks bad websites – all while protecting your encryption and network speeds.
If you choose to use TLSI despite these risks – be sure to read the NSA’s report. It describes mitigation techniques for every risk described.