Keeping protection at a high level without HTTPS scanning

[senna 3]

Hi,

in principle I don't like the idea of HTTPS scanning or TLS interception. I share views and arguments that TLS interception weakens the idea of a secure, private (encrypted) tunnel between a client and a server. I can't imagine why I want anyone to scan that information. In my opinion it s a matter of privacy. I am still not convinced that https scanning does more good than harm.

If I am right ESET scans HTTPS traffic by default. I guess the idea behind is to catch bad encrypted traffic. So far I turned HTTPS/SSL scanning off.

Isn't there any other way blocking bad https encrypted websites without tls interception? How much of protection do I have to sacrifice by turning HTTPS/SSL scanning off?

Cheers.

[Marcos 5,450]

Without SSL/TLS filtering, it's not possible to scan the communication and therefore possible malware on https sites may be downloaded undetected or malicious https urls may not be blocked. Also with future versions of Chrome marking all http sites as not secure, even more malicious websites will change to https.

[itman 1,801]

For web sites where privacy is a concern such as healthcare providers and the like, you can exclude their associated certificates from being scanned. I do.

Also note that Eset's SSL protocol scanning does not scan every HTTPS site. Those that are trusted via internal whitelist and many sites with EV certificates are not scanned.

[senna 3]

Isn't there any way of blocking https:// encrypted sites without tls interception?

E.g. adding some kind of "browsing protection" checking the sites that are being visited against lists of reported phishing and malware-spreading sites.

[Marcos 5,450]

With SSL/TLS filtering disabled you can block the hostname, e.g. https://domain.com but not https://domain.com/malware and urls with a path on the blacklist won't be applied either.

Also if an application (malware) communicates with a server over https, this communication cannot be scanned unless you enable SSL/TLS filtering.

[senna 3]

I checked some of the settings and was wondering why programs like my password manager or my cloud encryption tool are being scanned too? They appear in the "List of SSL filtered applications". These are trustable software applications. I am not concerned that any of this peace of software would throw malware at me. 

[Marcos 5,450]

7 minutes ago, senna said:

I checked some of the settings and was wondering why programs like my password manager or my cloud encryption tool are being scanned too? They appear in the "List of SSL filtered applications". These are trustable software applications. I am not concerned that any of this peace of software would throw malware at me. 

Because they communicate over https and the certificate they use is not an EV certificate (typically used by banks for instance). You can exclude particular applications or certificates from filtering.

[Azure Phoenix 11]

Quick question since I was curious. 

@senna What is your opinion about http scanning? Since I feel the argument you have made can in part apply to it as well.

[senna 3]

I am undiceded on this topic, following some of the news, e.g.  "the security Impact of https interception" or "https interceptions weakens tls security".

You may find some examples and arguments why https scanning does more harm than good. I definitely feel uncomfortable knowing of software scanning my encrypted connections.

Edited July 19, 2018 by senna

[Marcos 5,450]

If SSL/TLS filtering is not properly implemented then yes, it can cause more harm then good. However, that is not the case of ESET. Whether a website uses http or https doesn't tell anything about whether it can be trusted or not or whether it's benign or malicious. As we have already said, not all https communication is filtered and scanned; EV certificates and trusted sites are excluded by default.

[itman 1,801]

The problem is simply everything in short order will be HTTPS communication. This is because the browser manufactures wish it so and existing initiatives such as HTTPS Everywhere.

The real solution lies with browser manufactures allowing an interface into the browsers for AV vendors to scan HTTPS traffic after it decrypts. That will never happen since as far as the browser manufacturers are concerned, the AV vendors need to stay out of the browsers period; this includes hook injection. Also the AV vendors are a "favorite whipping boy" for the browser manufactures in that they will always blame them first for any operational or security issues with their browsers whether related or not. 

The bottom line is SSL/TLS is horrible broken and that really needs to be fully addresses by the global security community. Search the web for related articles on this issue.

[senna 3]

Thanks for all the comments on this topic. I appreciate alot. I am very interested how ESET handles HTTPS scanning in detail. What happens to my data, how does it de- and encrypt my connection? How does ESET handle scanned traffic including usernames, passwords, pivate data (documents, pictures, etc.)?

I couldn't find any detailed information on this so far.

[senna 3]

In addition to my questions above: I am also a Mac user. As far as I know ESET is not scanning HTTPS traffic on Macs. Why is this handeled differently?

Edited July 20, 2018 by senna

[Peter Randziak 1,181]

Hello @senna,

3 hours ago, senna said:

how ESET handles HTTPS scanning in detail

We decrypt the traffic to scan it so the appropriate rules can be evaluated and also the objects of our interest (like executables, scripts and so) can be sent to the scanner.

If the scanner finds malicious object / it matches blocking rule, the traffic is stopped. If the content is O.K. we encrypt it again and send to the original destination i.e. the browser.

11 minutes ago, senna said:

In addition to my questions above: I am also a Mac user. As far as I know ESET is not scanning HTTPS traffic on Macs. Why is this handeled differently?

The SSL/TLS scanning is not yet implemented on the macOS platform, but we plat to have it there as well. 

Regards, P.R.