US-CERT Warns HTTPS Inspection May Degrade TLS Security

Security tools that proxy and inspect HTTPS traffic create a blindspot for network administrators trying to determine whether communication between clients and servers is secure.

Recent academic work looking at the degradation of security occurring when HTTPS inspection tools are sitting in TLS traffic streams has been escalated by an alert published Thursday by the Department of Homeland Security.

DHS’ US-CERT warned enterprises that running standalone inspection appliances or other security products with this capability often has a negative effect on secure communication between clients and servers.

“All systems behind a hypertext transfer protocol secure (HTTPS) interception product are potentially affected,” US-CERT said in its alert.

HTTPS inspection boxes sit between clients and servers, decrypting and inspecting encrypted traffic before re-encrypting it and forwarding it to the destination server. A network administrator can only verify the security between the client and the HTTP inspection tool, which essentially acts as a man-in-the-middle proxy. The client cannot verify how the inspection tool is validating certificates, or whether there is an attacker positioned between the proxy and the target server.

A paper titled “The Security Impact of HTTPS Interception” and published in January by prominent researchers and academics establishes that these appliances “drastically reduce” the security of TLS connections, and that 62 percent of traffic has reduced security and 58 percent of connections between appliances and target servers have “severe vulnerabilities.”

“Because the HTTPS inspection product manages the protocols, ciphers, and certificate chain, the product must perform the necessary HTTPS validations,” US-CERT said in its alert Thursday. “Failure to perform proper validation or adequately convey the validation status increases the probability that the client will fall victim to [man-in-the-middle] attacks by malicious third parties.”

Two years ago, the Software Engineering Institute at Carnegie Mellon University published its own cautionary report on the risks posed by inspection tools. Will Dormann, the SEI report’s author and senior vulnerability analyst, told Threatpost that HTTPS inspection serves a purpose in providing visibility into encrypted traffic, but it does come at a cost.

“From the client perspective, I can only see what happens between me and the inspecting devices. I have no idea what happens on the other side of that device,” Dormann said. “The browser can tell me I’m using a secure cipher, TLS 1.2, or SHA256, but the problem is where the appliance is deployed. I don’t know what’s happening on the other side of it. It could be using old SSL or weak ciphers. There are a number of things happening behind the scenes putting traffic risk.

“When I wrote that blog, I was not saying no one should do HTTPS inspection or that it’s inherently a bad thing,” Dormann said, offering as an example a situation where a client is infected and using HTTPS to communicate, and a network admin might appreciate that visibility into the encrypted tunnel. “They do give you visibility into things you could not otherwise see. I wanted to make sure people were aware that they’re not getting that ability for free. The cost is that with HTTPS inspection, you are decreasing the security of HTTPS in the end.”

TLS is supposed to ensure clients securely communicate with servers and validate the target server is indeed the intended destination. With HTTPS inspection appliances and software, clients don’t talk directly to the target server.

“By the whole definition of HTTPS, intercepting devices violate the underlying capability TLS aims to give you. Am I talking to the server I think I’m talking to? If you’re doing HTTPS inspection, you’re not talking to the server, the appliance is,” Dormann said.

Venafi, a vendor whose platform does HTTPS inspection, said Thursday’s alert ignores a critical role they play.

“It’s just not about employee use of the Internet–it’s also about threats from web applications that seek to hide, move, and expand across networks,” said Kevin Bocek, Venafi’s chief security strategist.

“Organizations need SSL inspection to examine application, cross-network, cross-cloud, cross data center and IoT communications. Failing to inspect these communications makes the security technology businesses rely on to protect them from cyber attacks far less effective,” Bocek said. “SSL inspection is the only way to protect against threats hiding in incoming and cross-network encrypted traffic.”

The January paper—written by researchers at Google, Mozilla and Cloudflare, and academics from the University of Michigan, the University of Illinois, the University of Cal-Berkeley and the International Computer Science Institute—points out that many inspection products do not properly verify the server’s certificate chain before forwarding client data. Also, certificate-chain verification errors are forwarded to the client, fooling the client into thinking the operations went as planned.

“Organizations using an HTTPS inspection product should verify that their product properly validates certificate chains and passes any warnings or errors to the client,” US-CERT said.

Dormann, meanwhile, said it would be difficult to determine whether an attacker could directly target this scenario, but should an attacker be aware of an interception proxy, he could realize the client would be less likely to detect an attack.

“The general idea for anyone doing HTTPS inspection or interception, it’s really removing the client’s ability to tell if anything bad is happening,” Dormann said. “If you’re talking to the server directly, your browser warns you about weak crypto or an untrusted CA, and the user could say something was going on. The problem with networks and enterprises that have these appliances doing HTTPS inspection is that it removes the ability for the client to tell them anything fishy is going on.”

Suggested articles


  • Jack in the Box on

    Basically, if a company is using a poor product and the IT/security staff is not configuring their proxy properly, there can be increased risk- from the users' limited perspective (inside the corporate network). The conclusion I think they want you to come to is the inspection/proxy products need to be better, and the IT staff needs to do a better job of both understanding and configuring it. Those are not bad points, but when you give people a word-math problem they don't always come to the conclusions you want them to. I see a need to improve the coding on both the proxy and the browser to address this. The distinction here is somewhat subtle and if I did not already fully understand the issue (proxy interception and trusted certificates) I could see how this article may confuse people. Maybe author intentionally makes some assumptions about the audience and awareness of the scope. I think many, even in the cryptography and IT communities, do not understand the operational challenges present in corporate and organizational perimeter security.
  • Dr. Hilliard Haliard on

    Executive summary: Encryption works better when it is not decrypted by bad guys.
  • paul on

    servers should be programmed to block all traffic below tls 1.2 & weaker than sha 256--so as to make i/net users lift their game--i/net users are 99% of the problem(s).also tls/ssl commercial cert sellers should sell commercial HTTPS cookies with their certs.& no private self signed cookies--500 bit encrypted cookies would great.-do you think this will ever happen? not likely in our lifetime.--paul

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.