James Steidl - Fotolia
HTTPS interception, middlebox models under fire
HTTPS interception in security products and services may be reducing security rather than improving it, according to US-CERT, which puts middleboxes in a precarious position.
Security products and services that intercept traffic sent between endpoints communicating with TLS could put customers' data at risk -- even if the products correctly implement HTTPS interception.
Enterprise network security appliances, sometimes referred to as middleboxes, use HTTPS interception to examine HTTPS traffic sent from inside the enterprise. However, middlebox examination of packets serves as a legitimized version of a man-in-the-middle attack, and the U.S. Computer Emergency Readiness Team issued an alert to enterprises warning that reliance on HTTPS interception may be harmful to security.
"Organizations that have performed a risk assessment and determined that HTTPS inspection is a requirement should ensure their HTTPS inspection products are performing correct transport layer security (TLS) certificate validation," the alert from US-CERT reads. "Products that do not properly ensure secure TLS communications and do not convey error messages to the user may further weaken the end-to-end protections that HTTPS aims to provide."
The US-CERT alert cited a research paper, "The Security Impact of HTTPS Interception," that highlighted concerns with HTTPS interception as implemented in security products and raised questions over whether those products actually improved overall security. The report included results of research comparing HTTPS interception implementation and performance across both enterprise middlebox appliances and client-side HTTPS interception products used for antivirus and malware protection.
"While the security community has long known that security products intercept connections, we have largely ignored the issue, believing that only a small fraction of connections are affected," the researchers wrote. "However, we find that interception has become startlingly widespread and with worrying consequences. We hope that by bringing these issues to light, we can encourage manufacturers to improve their security profiles and prompt the security community to discuss alternatives to HTTPS interception."
"HTTPS interception has been problematic for a long time," Nick Sullivan, head of cryptography at Cloudflare and co-author of the research paper, told SearchSecurity. In addition to weakening security, "intercepting proxies are holding back adoption of a new encryption protocol -- TLS 1.3. It was time for US-CERT to give a statement on the topic."
The problem with middleboxes
"The use of SSL inspection software reduces or completely prevents clients from successfully validating the identity of the servers that they are communicating with," wrote Will Dormann, vulnerability analyst at the CERT/CC, in a blog post referenced in the alert and published by the Software Engineering Institute at the Carnegie Mellon University. Failure to validate certificates can expose users to malicious man-in-the-middle attacks.
Issues with middlebox interception of HTTPS traffic are not new, but they have been receiving greater attention recently. For example, the recent Cloudbleed bug, which had the potential to expose protected data of users accessing websites through the Cloudflare content delivery network, was caused in part by the use of middleboxes and HTTPS interception.
"HTTPS comes with a guarantee that people between the user and the web server cannot read the contents of data, period. Your ISP, eavesdroppers on the local coffee shop Wi-Fi network, and whomever else listening cannot see your data, as long as HTTPS is functioning properly. The problem that US-CERT is discussing in their notification is one of how the endpoints -- client or server -- handle that last hop," Tod Beardsley, director of research at Rapid7, told SearchSecurity.
"Introducing an HTTPS inspection element necessarily introduces complexity in that communication channel, and therefore, increases the chances for bugs and vulnerabilities that adversaries can take advantage of. Because of this complexity, it's incumbent on US-CERT to at least raise awareness of this complexity issue, and I'm glad they're doing a public service by publishing an advisory on this technology."
Coping with HTTPS interception
Among the steps that enterprises should take, the US-CERT alert recommended organizations should verify their HTTPS inspection products are validating transport layer security (TLS) certificates correctly.
"Products that do not properly ensure secure TLS communications and do not convey error messages to the user may further weaken the end-to-end protections that HTTPS aims to provide. Many HTTPS inspection products do not properly verify the certificate chain of the server before re-encrypting and forwarding client data, allowing the possibility of a MiTM attack," the US-CERT alert added, noting "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."
US-CERT recommended using the website badssl.com for users to verify that HTTPS inspection products are certifying certificate chains properly.
The alert on HTTPS interception from US-CERT did not surprise some experts.
Scott Arciszewski, chief development officer at Paragon Initiative Enterprises, an Orlando, Fla.-based software consulting company, tweeted:
HTTPS Interception Weakens TLS Security
— Scott Arciszewski (@CiPHPerCoder) March 17, 2017
In other news, floods are wet!
"The US-CERT position on HTTPS interceptors is a fairly basic safety warning. It is absolutely possible to terminate HTTPS, decrypt and perform inspection on the 'inside' of the endpoint network, but it's very easy to take shortcuts there," Beardsley said. "The Superfish scandal of 2015 is an example of what not to do with HTTPS interception -- in that case, endpoint laptops were intercepting HTTPS with a universal wildcard certificate, which exposed web content to anyone who had the Superfish private key."
"An enterprise [that] wants the perceived benefits of HTTPS interception must be prepared to accept the real burdens of every advantage HTTPS otherwise provides -- and that's either so expensive that it breaks the cost/benefit analysis, or impossible, depending on who you ask," Paul Vixie, CEO of Farsight Security Inc. in San Mateo, Calif., and architect of domain name system (DNS) protocol extensions and applications, told SearchSecurity.
"HTTPS is one of the only tools of trust that enterprise has for the web, and so it's often and inappropriately targeted by security point-solutions that are each willing to discard a distant long term benefit in favor of an immediate but range-of-the-moment advantage," Vixie said. "The fact is, we should never have standardized a protocol that can be intercepted in this way, and we should never have allowed market momentum around such interception, and we should all have been talking about this starting years ago, and often."
What's next for HTTPS interception?
In light of the US-CERT alert, the future for HTTPS interception as a means of improving security may be limited.
"Real security, that passes the laugh test, is and must be end-to-end," Vixie said. "No matter what benefit an enterprise is hoping to get from HTTPS interception, a lower TCO would come from endpoint security agents. And if an enterprise can't control the security policy and agency of its endpoints, then that is their real problem, and one they won't be able to solve with HTTPS interception."
Sullivan said HTTPS interception isn't necessary for enterprise security. "HTTPS interception is a solution looking for a problem. Its goals can be met with stronger endpoint security features such as code signing and auto-updates without compromising the security of the data in transit. The industry has been going in that direction with Windows Defender and other more integrated endpoint solutions," Sullivan said.
"If you're browsing the web on a managed network with an interception proxy, the data you send by browsing the web is not private. The end-to-end encryption guarantee HTTPS usually provides does not apply."
