Security features that decrypt and inspect HTTPS traffic almost always harm security.
Some even introduce “severe vulnerabilities,” according to research from the Internet Society.
In The Security Impact of HTTPS Interception, researchers from Mozilla, Google, UC Berkley, and other organizations demonstrate how the growing trend of decrypting and inspecting TLS traffic is doing more harm than good.
The report defines HTTPS interception as when:
“Products monitor HTTPS connections by acting as transparent proxies that terminate the browser TLS session, inspect content, and establish a new connection to the destination server.”
The feature is also known as HTTPS web filtering, SSL inspection, TLS filtering, and other similar names. It’s found in many UTM firewalls and antivirus products (however, AccessEnforcer’s web filter is different, see why below).
The authors do not sugar-coat their findings about the feature:
“Interception products as a class have a dramatically negative impact on connection security.”
What’s Wrong with SSL Inspection?
The problem with HTTPS filtering comes in the second-half of the connection.
After a security product terminates the browser’s TLS connection, it inspects packets. If the content is allowed, the product begins a new TLS handshake by sending a Client Hello message to the destination server.
The hello message shows the TLS version and features supported by the security product’s TLS client. This includes ordered lists of cipher suites, compression methods, and extensions – all of which can contain additional parameters such as elliptic curves and signature algorithms.
Here’s the problem
Almost all of the security products included weak or deeply flawed TLS options in the Client Hello message.
The options were almost always worse than those allowed by the user’s web browser. Researchers also found widespread support for broken ciphers and a failure to verify the certificates of destination servers.
This can allow a man-in-the-middle attacker to intercept, downgrade, and decrypt content sent via HTTPs.
US-CERT even describes HTTPS inspection as a man-in-the-middle attack.
While most security products allowed weak or broken encryption, even if they mirrored the TLS parameters of the user’s browser, the risk introduced by breaking the encryption is greater than zero.
In short: the security products harmed the user’s security.
8 Billion HTTPS Handshakes
The report is the first comprehensive look at the impact of HTTPS interception in the wild, according to the authors.
Researchers took the following steps (check the report for technical details):
- Planned to monitor connection handshakes at three network vantage points: Mozilla Firefox update servers, a set of popular e-commerce websites, and the Cloudflare content distribution network.
- Created a method to detect inbound connections that used HTTPS interception.
- Created a method to identify security products doing the interception and also a method to identify the browser that initiated the connection.
- Graded the TLS features advertised in the security product’s Client Hello message and the features allowed by the user’s browser.
- Analyzed 7.75 billion HTTPS handshakes using these methods.
“For more than 85% of intercepted connections, we detect an invalid handshake based on the use of unsupported extensions, ciphers, or curves.”
Among the security products that perform this type of inspection, “nearly all reduce connection security and many introduce severe vulnerabilities,” according to the report.
“Alarmingly, not only did intercepted connections use weaker cryptographic algorithms, but 10–40% advertised support for known-broken ciphers that would allow an active man-in-the-middle attacker to later intercept, downgrade, and decrypt the connection.”
Security Products that Harm Security
The security products reviewed in the study are mostly “middleboxes” and client-side antivirus clients (examples of “middleboxes” include UTM firewalls and other network edge devices).
These products intercept HTTPS traffic in an attempt to detect and block malicious content that uses the TLS to avoid inspection.
Of the two product types, middleboxes performed the worst.
“Security is degraded for 62.3% of connections that traverse a middlebox and an astounding 58.1% of connections have severe vulnerabilities,” according to the report.
“Many of the vulnerabilities we find in antivirus products and corporate middleboxes—such as failing to validate certificates and advertising broken ciphers—are negligent and another data point in a worrying trend of security products worsening security rather than improving it.”
“The default configurations for eleven of the twelve middleboxes we tested weaken connection security, and five of the twelve products introduce severe vulnerabilities that would enable future interception by a man-in-the-middle attacker.”
Researchers gave only a single middlebox a grade of A, noting that it mirrored browser ciphers instead of changing them. Among the rest, five were given F’s and six were given C’s.
However, client-side security software (such as anti-virus) also performed poorly.
“We find that nearly all the client-side security products we tested reduce connection security and ten introduce severe vulnerabilities,” according to the report.
The problem is not with any single product, but instead with the entire category of solutions that decrypt and inspect HTTPS traffic.
“As a class, interception products drastically reduce connection security.”
Calyptix’s HTTPS Web Filter is Different
You might wonder, if HTTPS filtering is so bad, why is it available in AccessEnforcer UTM Firewall from Calyptix?
Good question. The answer is that the HTTPS filter in AccessEnforcer is different.
Most security products filter HTTPS traffic using the method described above – i.e. they break the encryption, inspect the traffic, and create another TLS connection with the destination server to forward the traffic.
AccessEnforcer does not break the encryption.
Instead, AccessEnforcer uses a proprietary method of analyzing web server certificate fields to determine if a connection is allowed. The browser’s encryption is not affected, and the firewall is also not bogged down with a resource intensive process.
The result is an HTTPS web filter that doesn’t bog down your network or harm your security.