The U.S. Department of Homeland Security’s US-CERT has issued a new alert warning about problems with some HTTPS inspection products.
The alert, ‘HTTPS Interception Weakens TLS Security (TA17-075A)’ warns that “Failure [by the SSL/TLS interception software] 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.”
This alert follows the publication earlier this month of a detailed study of the problem. The study concluded that HTTPS interception before the endpoint (such as that done by anti-virus products) can weaken rather than strengthen network security. The CERT Coordination Center (CERT/CC) first raised the issue two years ago in a blog post titled ‘The Risks of SSL Inspection’ — but US-CERT has only now issued an alert.
The reason for this long delay between unofficial and official warnings is probably twofold. Firstly, the “blog post for CERT was mostly an observation based on a very small sample set of HTTPS inspection solutions that I was able to test myself,” author Will Dormann, a vulnerability analyst at CERT/CC, told SecurityWeek. “It was posed as an issue that needed to be investigated, with the goal that folks with the devices in question could perform their own testing and ideally get back to us with the results.”
It was, in short, a valid but not-scientific analysis of the problem. The new scientific paper, he adds, “appears to have used my blog post as motivation. But they were able to take it much further and provide some real-world statistics about the prevalence of HTTPS interception. This presumably took some time to develop and collect results.”
Dormann believes that the arrival of this paper and the availability of an easy-to-use test website (badssl.com) have combined to make the time right for a US-CERT alert.
The second motivation for the alert is the increasing use of encryption by malicious actors to bypass security defenses and to hide data exfiltration. Dell highlighted the problem in its 2016 Threat Report. At least 900 million users were affected by encrypted hacks in 2015, it said.
Industry’s response has been to install HTTPS inspection software to unpack the encryption and allow traffic inspection. This interception can be found in a range of products including anti-virus, firewalls, DLP, and secure web gateways. They operate by performing the customer’s own ‘legal’ MitM attack on the traffic — but in doing so they break the end-to-end encryption from the trusted server to the end client.
The problem comes in how the HTTPS inspection product then attempts to provide its own ‘trust’ to the client — and tests have shown that many of the products are lacking. “Many HTTPS inspection products do not properly verify the certificate chain of the server before re-encrypting and forwarding client data,” warns US-CERT, “allowing the possibility of a MitM attack. Furthermore, certificate-chain verification errors are infrequently forwarded to the client, leading a client to believe that operations were performed as intended with the correct server.” It adds, “Because client systems may connect to the HTTPS inspection product using strong cryptography, the user will be unaware of any weakness on the other side of the HTTPS inspection.”
This leaves industry with a difficult choice: to inspect HTTPS traffic for reasons of security and risk increasing the attack surface in the process; or to leave alone and find other ways to protect against encrypted bad intent. “There are compelling business reasons for corporations to be able to ‘see into’ encrypted traffic flows,” comments Erka Koivunen, chief information security officer at F-Secure Corporation. “For instance, financial institutions may want to extend their control into encrypted traffic flows in terms of content inspection and Data Loss Prevention. It is no wonder the vendor community is pressurized to come up with ‘innovative’ ways to terminate HTTPS encryption by means of MitM.”
But he doesn’t think using good-intentioned MitM is the answer. “The research by CERT/CC and the US-CERT advisory seem to confirm our point of view,” he told SecurityWeek. “MitM’ing HTTPS traffic adds unnecessary complexity and creates a risky tradeoff between content inspection and communications security.” F-Secure has chosen not to provide an HTTPS inspection capability.
“Most of the functionality can, however, be enforced at an endpoint level,” he added, “and this is where F-Secure has committed to excel. We believe that endpoint security solutions will continue to play a central role in enterprise security. While the ‘other endpoint’ will increasingly reside in the cloud, the security stack needs to be complemented with security in the cloud.”
This won’t suit all organizations; particularly those that choose ‘security in depth’. US-CERT recommends that whether HTTPS inspection is employed or not, organizations should take additional steps to secure communications — and points to the earlier alert (TA15-120A): Securing End-to-End Communications. This recommends using the latest version of TLS or SSL; using certificate pinning; the use of DNS-based Authentication of Named Entities (DANE); and using network notary services.
For HTTPS inspection products, suggests US-CERT, organizations could “use badssl.com as a method of determining if their preferred HTTPS inspection product properly validates certificates and prevents connections to sites using weak cryptography.”
It is true, High Tech Bridge CEO Ilia Kolochenko, told SecurityWeek, “many organizations wrongly implement HTTPS interception by forcing all their client devices to trust any certificate. In a corporate environment, this can significantly facilitate phishing and drive-by-download attacks.” But, he added, “US-CERT’s recommendations, as well as HPKP usage, can solve this problem in a quite reliable manner.”
