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:

VB2019 conference programme announced

VB is excited to reveal the details of an interesting and diverse programme for VB2019, the 29th Virus Bulletin International Conference, which takes place 2-4 October in London, UK.

VB2018 paper: Under the hood - the automotive challenge

Car hacking has become a hot subject in recent years, and at VB2018 in Montreal, Argus Cyber Security's Inbar Raz presented a paper that provides an introduction to the subject, looking at the complex problem, examples of car hacks, and the…

VB2018 paper and video: Android app deobfuscation using static-dynamic cooperation

Static analysis and dynamic analysis each have their shortcomings as methods for analysing potentially malicious files. Today, we publish a VB2018 paper by Check Point researchers Yoni Moses and Yaniv Mordekhay, in which they describe a method that…

VB2019 call for papers closes this weekend

The call for papers for VB2019 closes on 17 March, and while we've already received many great submissions, we still want more!

Registration open for VB2019 ─ book your ticket now!

Registration for VB2019, the 29th Virus Bulletin International Conference, is now open, with an early bird rate available until 1 July.

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.