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
googleplus.png
reddit.png

 

Latest posts:

Firefox 59 to make it a lot harder to use data URIs in phishing attacks

Firefox developer Mozilla has announced that, as of version 59 of the browser, many kinds of data URIs, which provide a way to create "domainless web content", will not be rendered in the browser, thus making this trick - used in various phishing…

Standalone product test: FireEye Endpoint

Virus Bulletin ran a standalone test on FireEye's Endpoint Security solution.

VB2017 video: Consequences of bad security in health care

Jelena Milosevic, a nurse with a passion for IT security, is uniquely placed to witness poor security practices in the health care sector, and to fully understand the consequences. Today, we publish the recording of a presentation given by Jelena at…

Vulnerabilities play only a tiny role in the security risks that come with mobile phones

Both bad news (all devices were pwnd) and good news (pwning is increasingly difficult) came from the most recent mobile Pwn2Own competition. But the practical security risks that come with using mobile phones have little to do with vulnerabilities.

VB2017 paper: The (testing) world turned upside down

At VB2017 in Madrid, industry veteran and ESET Senior Research Fellow David Harley presented a paper on the state of security software testing. Today we publish David's paper in both HTML and PDF format.