Sometimes a headline succinctly and cleverly captures the essence of a simple situation. Note last week’s headline about the apprehension of a nearly naked suspect: “Man in Boxers Leads Police on Brief Chase.”
Other times, the nuance of a complicated issue gets lost in a headline that’s meant to scare—especially in infosec journalism. I’m thinking specifically of the coverage around the US CERT warning TA17-075A “HTTPS Interception Weakens TLS Security.” Reading a headline like “US Gov Backs Google’s Alarm: Warns Against HTTPS Interception Products,” you’d think that SSL interception is working against security, right? The CSO article reports on what Google says about what CERT says about a paper published on the quality of SSL interceptors called “The Security Impact of HTTPS Interception.”
If you barely followed that last sentence, let me boil away the tallow for you.
At issue is the use of transparent SSL/TLS interception devices that spoof the endpoint of the server in order to sit as a man in the middle between a client (typically a browser) and an HTTPS web server. These interception devices are installed in enterprise and government agency data centers to allow the local security team to inspect what’s going into and out of the network. The paper, and the CERT warning, point out that many of these SSL interception devices do SSL poorly. But that doesn’t mean the only choice is not to use them or that they’re not needed.
The essence of this false dichotomy is that it completely ignores the question of why the interception is happening in the first place: security inspection.
Certificate Verification Fallacies
Classic SSL interceptors are notoriously lackadaisical about certificate verification. Historically, this comes from the fact that everyone used to be lackadaisical about certificates and certificate chains. And if an executive couldn’t get to his or her March Madness bracket because of a certificate chain error, which may or may not have been an error at the server, the SSL interceptor was the first thing to blame. So SSL interceptor vendors never really had a requirement to be too strict because their job was to provide visibility, not privacy, to the IT administrators.
The “Security Impact of HTTPS Interception” paper quantified all these fallacies. Amusingly, the academic authors of the paper appeared to have little idea how frequently SSL interceptors are deployed in the private sector: “We find more than an order of magnitude more interception than previously estimated and with dramatic impact on connection security.”
Yes, it’s true, nearly everyone in an enterprise uses SSL interceptor technology, because their number one threat, this year and every year for the last 10 years has been malware; ransomware being just the latest incarnation of it. Rigid certificate verification doesn’t catch malware entering the enterprise: SSL interception combined with IDS/IPS, sandboxing, and anti-virus does (at least sometimes). In fact, today’s malware authors are smart enough to hide their malware inside SSL to bypass perimeters where interceptors are not in use!
To suggest that administrators ditch their SSL interceptors in favor of better transport layer security is a false dichotomy: an organization should have both visibility and security. Not one or the other.
Inconvenient Truth: SSL Interception Is Still a Kludge
It’s not just the authors of the paper who had little idea how ubiquitous Interceptors are; most people have little idea how often their SSL/TLS connections are being intercepted by a transparent proxy. The browsers know when it’s happening and they disable lots of their security features (like certificate pinning). But the user doesn’t know.
Acccording to the “Security Impact…” paper, SSL interceptor vendors’ attempts to get a TLS extension that would provide a safer, sanctioned means of interception “have been met with great hostility within the standards groups.”
To be charitable, one could say that the IETF TLS standards group is not in favor of such an extension because any official back door could quickly become an unofficial back door and besides, “We’re trying to build a more secure internet!” But in reality, the current IETF group, bless their hearts, come from academia or organizations like Google, Cloudflare, and Akamai, who have an interest in securing their own stuff and aren’t in the business of securing other people’s. Some of them have little idea what a modern enterprise security architecture looks like.
The disdain for security in the real world in favor of an ideal TLS protocol drives the authors of the “Security Impact…” paper to call for consensus within the community “to develop sustainable, long-term solutions.”
What’s the Fix?
Consensus for the value of interception looks further away than ever with Google, Cloudflare, and Akamai driving the standards committee for TLS 1.3. In the meantime, is there anything a security architect can do today?
The conclusion of the CERT warning says “Organizations using an HTTPS inspection product should verify that their product properly validates certificate chains and passes any warnings or errors to the client.”
The badssl.com website listed in the paper and the CERT warning is actually a pretty nifty tool to see at a glance how well your interceptor is doing at forwarding your TLS. It makes the bad transparent TLS proxy a lot less transparent.
If you aren’t seeing all those green checkboxes, maybe it’s time to find a better SSL intercept proxy. Or, as the “Security Impacts…” authors may be now realizing, interceptors can (and should) be tuned with higher security settings. Check with your interceptor vendor, who might be interested in helping you tighten your settings.
And then sit back and wait for the SSL/TLS community to come to consensus that we should probably recognize that organizations are MitM-ing their end users because they have no other choice.
Tags: