Some HTTPS inspection tools might weaken security

Companies that use security products to inspect HTTPS traffic might inadvertently make their users’ encrypted connections less secure and expose them to man-in-the-middle attacks, the U.S. Computer Emergency Readiness Team warns.

US-CERT, a division of the Department of Homeland Security, published an advisory after a recent survey showed that HTTPS inspection products don’t mirror the security attributes of the original connections between clients and servers.

HTTPS inspection checks the encrypted traffic coming from an HTTPS site to make sure it doesn’t contain threats or malware. It’s performed by intercepting a client’s connection to an HTTPS server, establishing the connection on the client’s behalf and then re-encrypting the traffic sent to the client with a different, locally generated certificate. Products that do this essentially act as man-in-the-middle proxies.

In a typical enterprise environment, an HTTPS connection can even be intercepted and re-encrypted multiple times: at the network perimeter by gateway security products or data leak prevention systems and on endpoint systems by antivirus programs that need to inspect such traffic for malware.

The problem is that users’ browsers no longer get to validate the real server certificates because that task falls to the interception proxy. And as it turns out, security products are pretty bad at validating server certificates.

Researchers from Google, Mozilla, Cloudflare, University of Michigan, University of Illinois Urbana-Champaign, University of California, Berkeley and the International Computer Science Institute recently conducted an investigation of HTTPS inspection practices.

They found that more than 10 percent of HTTPS traffic that originates from the U.S. and reaches Cloudflare’s content delivery network is being intercepted. So are 6 percent of connections to e-commerce websites.

An analysis found that 32 percent of e-commerce and 54 percent of Cloudflare HTTPS connections that were intercepted became less secure than they would have been had users connected directly to the servers.

“Alarmingly, not only did intercepted connections use weaker cryptographic algorithms, but 10 to 40 percent advertised support for known-broken ciphers that would allow an active man-in-the-middle attacker to later intercept, downgrade, and decrypt the connection,” the researchers said in their paper.

The reason is that browser makers have had a long time and the proper expertise to understand the potential quirks of TLS connections and certificate validation. There arguably are no better client-side implementations of TLS — the encrypted protocol used for HTTPS — than the ones in modern browsers.

Security product vendors use outdated TLS libraries, customize them and even attempt to re-implement some of the protocol’s features, resulting in serious vulnerabilities.

Another widespread problem signaled by US-CERT in their advisory is that many HTTPS interception products don’t properly validate the certificate chains presented by servers.

“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,” the organization said.

On the BadSSL website, organizations can check if their HTTPS inspection products improperly validate certificates or allow for insecure ciphers. The client test from Qualys SSL Labs also can check for some known TLS vulnerabilities and weaknesses.

The CERT Coordination Center at Carnegie Mellon University has published a blog post with more information on the common pitfalls of HTTPS interception, as well as a list of products that may be vulnerable.

Got a comment, head to Facebook to add it.