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:

VB2018 paper: Office bugs on the rise

At VB2018 Sophos researcher Gábor Szappanos provided a detailed overview of Office exploit builders, and looked in particular at the widely exploited CVE-2017-0199. Today we publish his paper and release the video of his presentation.

VB2018 video: The Big Bang Theory by APT-C-23

Today, we release the video of the VB2018 presentation by Check Point researcher Aseel Kayal, who connected the various dots relating to campaigns by the APT-C-23 threat group.

VB2019 London - join us for the most international threat intelligence conference!

VB calls on organisations and individuals involved in threat intelligence from around the world to participate in next year's Virus Bulletin conference.

VB2018 paper: Tracking Mirai variants

Today, we publish the VB2018 paper by Qihoo 360 researchers Ya Liu and Hui Wang, on extracting data from variants of the Mirai botnet to classify and track variants.

VB2018 paper: Hide'n'Seek: an adaptive peer-to-peer IoT botnet

2018 has seen an increase in the variety of botnets living on the Internet of Things - such as Hide'N'Seek, which is notable for its use of peer-to-peer for command-and-control communication. Today, we publish the VB2018 paper by Bitdefender…

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.