Security products and HTTPS: let's do it better

Posted by   Martijn Grooten on   Feb 27, 2017

It is one of the most hotly discussed topics in the security community: is it acceptable for a security product to intercept encrypted HTTP communication (HTTPS) to analyse its content?

First, those who are against the practice point out that it breaks the end-to-end principle of HTTPS. This is obviously true, but misses an important point: a compromise in one area of security could (sometimes) lead to improved security elsewhere, and thus a net win.

This will not apply to everyone; in particular it may not be true for most security professionals: they tend to have seriously hardened systems and a far better-than-average understanding of threats, thus reducing the risk of browsing the web to an acceptable level.

Most people are not security professionals though. They may not know they are browsing the Internet with an outdated browser plug-in, and may not be able to distinguish between a useful program and a rogue program with the same name that will infect their device with malware. For them, the web is full of dangers, more and more of which are using HTTPS. Security products, as we have repeatedly shown, can reduce the risk of infection significantly.

And with the increased use of HTTPS among both benign and malicious web traffic, many (though certainly not all) web security products have decided that they can't allow HTTPS to be a simple way to bypass their filters.

And that should be fine in principle, as long as the end-user has a way to contact those websites directly as well, should they want to. If done well, this makes the use of a security product that intercepts HTTPS an acceptable practice for an organization — whose users can use their phone or home Internet connection to avoid the interception — but an absolute no-no for a government.

httpsproxy.png

A second, more practical and possibly more compelling argument against intercepting HTTPS traffic, is that security products that do so could reduce the security of the HTTPS connection. A recent paper (pdf) doesn't paint a rosy picture.

In the paper, researchers from GoogleMozillaCloudflare and various universities looked at both client-side interception software (often part of an endpoint security suite) and TLS interception middleboxes, and found that only three out of the 32 products analysed offer the same TLS security as modern browsers do: most offer older ciphers or protocols, often with known vulnerabilities. In several cases, certificate validation is either broken or completely absent, allowing anyone with a privileged network position to silently read and modify all HTTPS traffic.

It would be tempting to see this as a strong argument for advising users not to trust a security product with their HTTPS traffic. But this is where things get complicated.

Though FREAK, POODLE and NoMore all sound scary, they are unlikely to be used by an attacker: they are either very resource-heavy or give an attacker very little information; in some cases both. In fact, though certainly not impossible, man-in-the-middle attacks in general are rare. It just isn't that easy for an attacker to get that privileged network position, especially not compared with the many other ways in which they can get the information they are after.

And this may be the main reason why there are quite a few security products that don't implement TLS properly: it doesn't really impact their customers, at least not the vast majority of them. Staying on top of developments among exploit kits and phishing sites does affect their customers, and that is likely where the majority of their efforts are directed.

Still, there is no excuse not to implement crypto properly, especially given that cryptographic libraries are available that make this a relatively straightforward task. If the mostly theoretical threat isn't a good enough reason, then let papers like the one mentioned here be the threat model you're missing. After all, they are a PR embarrassment and hurt not just the affected products, but the industry as a whole and thus get in the way of the far more important discussion about what is the best way to fend off web-based threats.

So if you read a paper like this, don't immediately conclude that the products mentioned are worthless. But do expect the vendors to fix the issues. The vulnerabilities may never be exploited in the wild, but without patching them, the vendors risk coming across as the job applicant whose cover letter is full of typos, because the interviewer will understand what they mean anyway.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VBSpam tests to be executed under the AMTSO framework

VB is excited to announce that, starting from the Q3 test, all VBSpam tests of email security products will be executed under the AMTSO framework.

In memoriam: Prof. Ross Anderson

We were very sorry to learn of the passing of Professor Ross Anderson a few days ago.

In memoriam: Dr Alan Solomon

We were very sorry to learn of the passing of industry pioneer Dr Alan Solomon earlier this week.

New paper: Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

In a new paper, researchers Aditya K Sood and Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited in order to gather threat intelligence, and present a model of mobile AppInjects.

New paper: Collector-stealer: a Russian origin credential and information extractor

In a new paper, F5 researchers Aditya K Sood and Rohit Chaturvedi present a 360 analysis of Collector-stealer, a Russian-origin credential and information extractor.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.