TLS Interception: Good, Bad, or Just Plain Ugly?

TLS Interception: Good, Bad, or Just Plain Ugly?

Infosec professionals are well familiar with the phenomenon of Transport Layer Security (TLS) interception. For everyone else, some background: TLS is the successor to SSL, once the default encryption protocol. TSL provides the underpinnings for many common security protocols, including secure HTTP (HTTPS).

Protocols like TLS are intended to keep web-based applications safe via encryption and authentication. But many security products intercept TLS-based communications as part of standard operation, and some popular browsers (including Chrome and Firefox) support it. Moreover, many “middleboxes” (typically firewalls and network address translation devices) intercept TLS communications by design. Is this a good idea?

Man in the Middle Attacks, Feb 2017 (Source: Durumeric, et. al)

A recent paper by researchers at Google, Mozilla, Cloudflare, the International Computer Science Institute, the University of Michigan, the University of Illinois at Champaign-Urbana, and the University of California at Berkeley argues that it’s not.

The paper falls short of calling for an end to TLS interception, but the authors argue that intercepting TLS can inject vulnerabilities into a connection that’s presumed secure.

The big issue is that with TLS interception, a middlebox or software needs to validate itself to the initiator of the TLS session by providing a certificate. Typically, software injects a self-signed CA certificate into the client browser’s root store at install time. With network devices, the network administrator sets up firewall or NAT box’s certificate. And this “self-certification” can, and does, weaken security. As the authors note: “The default configurations for eleven of the twelve middleboxes we tested weaken connection security, and five of the twelve products introduce severe vulnerabilities that would enable future interception by a man-in-the-middle attacker.”

To put it bluntly, this is not good. There’s really no point in deploying security products and protocols if you intentionally break them. As the US Computer Emergency Readiness Team (CERT) explains in its recent alert, TLS interception can leave you vulnerable to man-in-the-middle attacks.

As an infosec professional, what should you do?
Some recommendations:

  • Work with your network security team to develop configurations that are more robust than the default configurations—and subject the setup to validation testing.
  • Pressure your security vendors not to implement TLS interception.
  • Test for, and measure, the presence of TLS interception in your organization, with the goal of using only where absolutely necessary.