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:

Haroon Meer and Adrian Sanabria to deliver VB2019 closing keynote

New additions to the VB2019 conference programme include a closing keynote address from Thinkst duo Haroon Meer and Adrian Sanabria and a talk on attacks against payment systems.

Free VB2019 tickets for students

Virus Bulletin is excited to announce that, thanks to generous sponsorship from Google Android, we are able to offer 20 free tickets to students who want to attend VB2019.

VB2018 paper: Lazarus Group: a mahjong game played with different sets of tiles

The Lazarus Group, generally linked to the North Korean government, is one of the most notorious threat groups seen in recent years. At VB2018 ESET researchers Peter Kálnai and Michal Poslušný presented a paper looking at the group's various…

Book your VB2019 ticket now for a chance to win a ticket for BSides London

Virus Bulletin is proud to sponsor this year's BSides London conference, which will take place next week, and we have a number of tickets to give away.

First 11 partners of VB2019 announced

We are excited to announce the first 11 companies to partner with VB2019, whose support will help ensure a great event.

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.