The US Government’s Computer Emergency Readiness Team (US-CERT) has joined a growing number of voices calling on vendors that offer HTTPS traffic inspection to clean up their act on crypto.
Researchers at Google, Mozilla and Cloud recently accused several well-known security brands that sell HTTPS inspection products of creating a less secure connection for users than browsers. These products are by organizations to inspect encrypted traffic for malware.
The researchers found that HTTPS inspection was widespread and that many products used crypto libraries with known vulnerabilities. One startling finding was that 11 of 12 network appliances incorrectly validated SSL certificates, meaning these appliances could connect a browser to a bogus site instead of rejecting it as the browser would have without the interception software.
In an alert on Wednesday, US-CERT said “HTTP interception weakens TLS security” and told organizations that if they need HTTPS inspection they should ensure these products are “performing correct transport layer security (TLS) certificate validation.”
“Because the HTTPS inspection product manages the protocols, ciphers, and certificate chain, the product must perform the necessary HTTPS validations,” US-CERT’s alert says.
“Failure to perform proper validation or adequately convey the validation status increases the probability that the client will fall victim to MiTM attacks by malicious third parties.”
The alert was issued in response to a report by Will Dormann of Carnegie Mellon University’s CERT/CC who assessed 58 products for a range of SSL certificate errors using its man-in-the-middle proxy VM, CERT Tapioca. The tool checks for apps that fail to validate certificates.
“SSL inspection is much more widespread than I suspected,” he said, pointing to its presence in secure web gateways, firewalls, data loss prevention (DLP) products and other applications.
As with the earlier research, he found many applications that perform SSL inspection have flaws that put users at greater risk compared than the browser.
“Sure, there may be reasons why a network administrator may want to look into traffic that should be protected by SSL or TLS,” he writes. “But what people may not realize are the security impacts of deploying software that does not do SSL inspection at least as well as the browsers do.”
As he explains, in situations where interception is used, people have no option but to completely trust that the SSL inspection software is doing it right. He points to seven common ways they don’t, including a product sharing the same root CA certificate, and insufficient validation of the certificate on systems it connects to.
He notes it’s an invalid assumption that SSL attempts to achieve end-to-end encryption, when it can only deliver point-to-point encryption. So, where SSL inspection software is between the client and server, the client really can only verify that it is communicating with the inspection software. And there’s no way for the client to tell if there’s another attacker in the middle of the inspection software and the intended server.
“Because of this lack of transparency, the client must assume that the SSL inspecting software is doing everything perfectly. Unfortunately, SSL-inspecting software does not do everything perfectly,” writes Dormann.
To Dormann this underscores the problem with the expectation of end-to-end encryption.
“The fact that "SSL inspection" is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken. Compounding the problem are the mistakes that SSL inspection software authors are making,” Dormann concludes.
Dormann lists all 58 products as possibly vulnerable to one of the seven flaws he points out, but notes that he didn't test them all.