I have some substantive posts in the works, but mostly this week hasn’t been good for blogging. In the meantime, I wanted to point readers to this fascinating talk by researcher Jeff Jarmoc, which I learned about through the Corelan team blog:

SSL/TLS Interception Proxies and Transitive Trust

SSL/TLS is entrusted with securing many of the communications services we take for granted in our connected world. Threat actors are also aware of the advantages offered by encrypted communication channels, and increasingly utilize encryption for exploit delivery, malware command-and-control and data exfiltration.

To counter these tactics, organizations are increasingly deploying security controls that intercept end-to-end SSL/TLS channels. Web proxies, DLP systems, specialized threat detection solutions, and network IPSs now offer functionality to intercept, inspect and filter encrypted traffic. Similar functionality is also present in lawful intercept systems and solutions enabling the broad surveillance of encrypted communications by governments. Broadly classified as “SSL/TLS Interception Proxies,” these solutions act as man-in-the-middle, violating the end-to-end security guarantees promised by SSL/TLS.

In this presentation we’ll explore a phenomenon known as “transitive trust,” and explain how deployment of SSL/TLS interception solutions can introduce new vulnerabilities. We detail a collection of new vulnerabilities in widely used interception proxies first discovered by the Dell SecureWorks CTU and responsibly disclosed to the impacted vendors. These vulnerabilities enable attackers to more easily intercept and modify secure communications. In addition, we will introduce a public web site that organizations can use to quickly and easily test for these flaws.

I can’t find Jeff’s slides or whitepaper at the moment (Update: The slides are now public. There’s a lot more to his talk than I cover in this post.) What I can tell from the summary is that Jeff is doing us all an invaluable favor — essentially, putting his hands deep in the scuzz to find out what’s down there.

To make a long story short, the answer is nothing good. The details are in the Corelan post (which, ironically, gives me a TLS error), but to sum it up: Jeff mostly focuses on what interception proxies do when the proxy receives an invalid certificate from a remote website — for example, one that is expired or revoked.

Normally your browser would be the one dealing with this, but in a MITM scenario you’re totally dependent on the proxy. Even if the proxy checks the certificate properly in the first place, they’re still in a tough place. They essentially have the following options:

1. Reject the connection altogether (probably safest)
2. Give users the option to proceed or abort (no worse than standard TLS)
3. Ignore the errors and make the connection anyway (run for the hills!) 

Jeff correctly points out that option (3) is the most dangerous, since it opens users up to all kinds of bad TLS connections that would normally ring alarm bells in your browser. Worse, this seems to be the default policy of a number of commercial interception proxies, mostly for unintentional/stupid reasons.

Beyond these default settings, it seems to be that there’s another question here, namely: how are these devices being configured in the field? My guess is that this depends greatly on whether the “victims” of interception know that their TLS traffic is being monitored. If deployers choose to do interception quietly, it could make a big difference in how a proxy will handle cert issues.

I stress that we’re now speculating, but let’s pretend that ACME corporation wants to intercept its employees’ TLS connections, but doesn’t actively want to advertise this fact.* This may restrict their options. For one thing, option (2) is probably out, since this would produce obvious messages on the end-users’ web browser. Even option (1) might be iffy, since some sites will simply not work, without any decent explanation. Hence — in speculation land — one could imagine some organizations deliberately choosing option (3), on the theory that being quiet is better than being secure.**

This is different than the vulnerabilities that Jeff addresses (which mainly deal with devices’ default settings), but it’s something I’ve been wondering about since I first heard of the practice. After all, you’ve gone to all this trouble to get a publicly-rooted MITM CA, now you’re going to advertise that you’re using it? Maybe, maybe not.

The world of TLS MITM interception is a fascinating one, and I can’t possibly learn enough about it. Hopefully we’ll soon learn even more, at least about the nasty CA-facilitated variant of it, as CAs start to respond to Mozilla’s recent ultimatum.

Notes:

* They may notify their employees somehow, but that’s different from reminding them on a daily basis. This isn’t totally nuts: it’s one speculative reason for deploying CA-generated MITM certificates, rather than generating an org certificate and installing it throughout your enterprise.

** I suppose there are workarounds for this case, such as re-writing the MITM cert to include the same class of errors (expiration dates, name errors) but I’d be utterly shocked if anyone uses them.