Q&A HTTPS scan: should you enable it?

amirr

Level 9
Jan 26, 2020
448
My friend wrote this to me:

Actually, I’d advise against using HTTPS filtering in any software, be it an antivirus solution (I disabled it in KIS) or in this case a content blocker.

I don’t remember if we discussed it already, but the main problem is: certificate obscuring.

You see, when such a system intercepts HTTPS connections, it basically receives the connection instead of the actual client (e.g. your browser), decrypts it, analyzes it (and filters it if need be), and re-encrypts it with its own self-signed certificate that it injects in the Windows Trusted Root store.
This poses two problems :
• As the certificate is self-signed, it’s not validated by a trusted root authority, rather acting as a root authority. It is generally a bad practice, even though it is a required step in the process ;
• More importantly, you have to trust the application to do the decryption, verifications, and encryption properly. The verification part is crucial: as your browser will display the filtering app’s certificate, it becomes the app’s job to verify the strength of the connection, the certificate chain, etc. of the originating site. It is not an easy task, and browser do it well, but I’ve seen examples of filtering apps not doing it very well at all (for instance, KIS didn’t use to warn of a bad certificate when it did filter secure connections. It does now.) ;
• Lastly, and more problematically, it obscures the origin of the certificate. Say I visit some site, I can see that the HTTPS connection is signed by a certificate by a trusted root, say, GlobalSign. If the next day I visit the same website and the certificate is now run by another emitter, it can raise questions. It can be harmless, but also a sign of a man-in-the-middle attack. However, if a filtering application is used, all I will see is their own “trusted” (self-signed) root, and I won’t notice anything. That, to me, is the worse problem (even more with EV certs, that are supposed to certify also the organization that the certificate belongs to, even if they will, sadly, disappear with time).

As a filtering browser extension, such as uBO or presumably AdGuard’s own extension sees requests before (on the request side) and after (on the response side) the encryption is run, it sees them as clear text anyway and doesn’t need to run this interception process. So to me, it’s actually a security risk, and not needed anyway (just the same, an antivirus would catch the file as it’s downloaded for instance if it was malicious, without having to intercept the HTTPS connection but rather reading the file contents).

*KIS: Kaspersky Internet Security.
 

SearchLight

Level 11
Verified
Jul 3, 2017
529
Just came across this old (2017) article but it too, like others have mentioned above advocates disabling HTTPS scanning:

Ditch the HTTPS Scanning feature of your antivirus

Then, I found this FAQ about HTTPS scanning from Avast which if one reads between the lines also seems to imply that it may not be that secure but that its purpose is to prevent malicious downloads, which like stated by others, a good AV would scan upon being downloaded anyway:

HTTPS scanning in Web Shield - FAQs | Official Avast Support

It is looking more and more like one should disable the feature as many have been arguing. Based on everything said so far, I think I will disable HTTPS scanning in my KSC Free. For me, one less possible vulnerability to worry about.
 
Last edited:

avatar

From ADGuard
Verified
Developer
May 23, 2014
96
You can't be serious. Cyprus is a tax haven not a privacy haven and your Wikipedia article says most employees and operations are still in Moscow.
I am dead serious. Cyprus is not a tax haven anymore. It is in EU, and we want AdGuard to be subject to EU laws and not Russian laws. While our CEO and a small team are in Cyprus, most of the developers are in Moscow indeed. You'd be surprised how widespread this configuration is among companies based in the valley.

Now that we have this sorted out, I would still like to insist on you stopping spreading disinformation. All this "subject to russian laws" boohoo does not make any sense.

Chromium team has to implement Manifest V3 because the risk of it being used for malicious purposes is too big
How in the world these things are even connected? The Chromium team wants to implement Manifest V3 to limit EXTENSIONS capabilities. And the reason for doing this is that they cannot keep Chrome Web Store secure and clean from malicious extensions so they are going to limit ALL extensions capabilities instead. The solution is broken on so many levels if you ask me.

My point is not an opinion, it's a regurgitation of what browser security devs are saying and have been saying for years
It'd be better if they provided better alternatives. However, instead of that, browser devs prefer to make things obscure and uncontrollable.
They say "do extensions instead" and implement Manifest V3. I can be doing it for hours, really. The point is simple - there is no viable alternative.

Also, I am not talking about just browsers. There are other apps, there are mobile and IoT devices, they all may be an attack vector.


The only "Pro" of HTTPS scanning is that it is the one and only technical measure to inspect encrypted connections.
It is definitely not "convenient" compared to extensions, for instance.


Sorry, but these points range from "completely irrelevant to HTTPS scanning" to "could be if HTTPS scanning is implemented badly".

In my opinion, here's how Pros and Cons should look like:

Pros:
The only way to control network traffic.

Cons:
If implemented badly, it can cause a multitude of different issues ranging from minor inconveniences to the ones introducing major security flaws.

Nobody's security model should be based on 'trust'. Everyone's security model should be based on trustless actors, minimizing the amount of trust required.
I prefer a more practical approach.

Here's my problem: I want to be able to control what applications on my computer and mobile phone do. It does not mean I don't trust them (btw, I don't), but the real world is complicated, developers use third-party libraries and services, these third-parties use other third-parties, and so on. And to feel safe, I want to be in control. Maybe (most likely) I am a control freak, whatever. HTTPS scanning is the only way I can achieve this. This is that simple. I need to put my trust in one entity (for instance, an AV) to be more or less sure that other entities don't do bad stuff.
 

avatar

From ADGuard
Verified
Developer
May 23, 2014
96
If the cert gets invalid which is used by the product/ company, ALL connections are insecure.
Same as using HTTP for everything.

I am not sure what you mean here, but it does not sound right.

First, no serious product uses a single cert, this is highly insecure. The cert used for decryption is always unique to your device. If for some reason it becomes invalid, your browser will consider all your HTTPS connections broken. It does not mean that there's no HTTPS anymore - there is. It just becomes almost unusable because the user needs to confirm every new domain manually. But even in this case, your connections continue to be secure.

Also nobody here answer why breaking TLS for analysing the content against malware is needed, before the OS and/ or AV get in the end.
What's the point?

Here is one (there are more): most of the modern browser exploits use Javascript. This is not a file that's downloaded to HDD, it needs to be scanned before your browser has loaded and executed it.
 

avatar

From ADGuard
Verified
Developer
May 23, 2014
96
• More importantly, you have to trust the application to do the decryption, verifications, and encryption properly. The verification part is crucial: as your browser will display the filtering app’s certificate, it becomes the app’s job to verify the strength of the connection, the certificate chain, etc. of the originating site. It is not an easy task, and browser do it well, but I’ve seen examples of filtering apps not doing it very well at all (for instance, KIS didn’t use to warn of a bad certificate when it did filter secure connections. It does now.) ;
There are good tests you can use to check the quality of your filtering software:

• Lastly, and more problematically, it obscures the origin of the certificate.
By the way, we solved this in AdGuard with the help of an "Assistant" browser extension: https://uploads.adguard.com/up04_Screenshot_c7fli.png
 

SecurityNightmares

Level 32
Verified
Jan 9, 2020
2,090
The Chromium team wants to implement Manifest V3 to limit EXTENSIONS capabilities
They implemented it because of better security and performance

Pros:
The only way to control network traffic.
Well, no. You can monitor DNS (which is most) and IP connections without the need to know what is in the packet.

Here is one (there are more): most of the modern browser exploits use Javascript. This is not a file that's downloaded to HDD, it needs to be scanned before your browser has loaded and executed it.
JavaScript exploits are very rare and fixed fast.
Modern browsers like Edge using strong sandboxing and isolation.
 

avatar

From ADGuard
Verified
Developer
May 23, 2014
96
Well, no. You can monitor DNS (which is most) and IP connections without the need to know what is in the packet.
DNS filtering software is kinda my expertise (see AdGuard DNS, AdGuard Home, etc, etc) so let me please comment.

It is easy for any software to avoid DNS filtering. Use DoH/DoT, load stuff from legit domains, simply use plain IP addresses. Besides that, being able to scan the response content is crucial for threats detection. What's the point of developing all these complicated heuristic algorithms if you cannot apply them.

JavaScript exploits are very rare and fixed fast.

Let's google "Chrome zero-day exploit 2020" and see what we get on the first page.

1. CVE-2020-6519 - allows bypassing CSP to run Javascript
2. CVE-2020-6418 - exploits a bug in Chrome's Javascript engine
3. A news piece about 11 zero-days discovered Google Project Zero in 2020. 5 of them were discovered in browsers: 3 in Firefox, 1 in IE, 1 in Chrome. All 5 are Javascript-based.
4. CVE-2020-6418 again
5. CVE-2019-5786 - potential RCE, exploitable with Javascript
6-10. Articles on CVE-2020-6418 and CVE-2020-6519 again.

I hope you've got the idea.
 

Jan Willy

Level 5
Jul 5, 2019
225
They implemented it because of better security and performance


Well, no. You can monitor DNS (which is most) and IP connections without the need to know what is in the packet.


JavaScript exploits are very rare and fixed fast.
Modern browsers like Edge using strong sandboxing and isolation.
Could increasing malware by HTTPS be a sign that the malware distributors speculate that convential defense methods have ended? HTTPS scanning is at least worth considering.
 

SecurityNightmares

Level 32
Verified
Jan 9, 2020
2,090
Could increasing malware by HTTPS be a sign that the malware distributors speculate that convential defense methods have ended?
Doesn't matter. You still can block malicious sites with DNS.
But the most important step is a secured system so the execution isn't possible - no matter if the source is http, https, ftp, ...
 
  • Like
Reactions: Protomartyr

Jan Willy

Level 5
Jul 5, 2019
225
Doesn't matter. You still can block malicious sites with DNS.
But the most important step is a secured system so the execution isn't possible - no matter if the source is http, https, ftp, ...
HTTPS scanning is an additional and effective way to detect malware at an early stage. It increases your protection. I know there are doubts about this method, but it's a trade-off.
 

MacDefender

Level 14
Verified
Oct 13, 2019
643
HTTPS scanning is an additional and effective way to detect malware at an early stage. It increases your protection. I know there are doubts about this method, but it's a trade-off.
Well it increases your protection against some threats and exposes you to others. For example if there's any flaws in how your AV inspects SSL certificates versus your browser, you could be more vulnerable to those issues. It would also allow drive-by attacks if there's exploitable certificate parsing bugs in your AV.

It's absolutely a trade off, whether you expect to encounter more HTTPs malware served from neutral/good reputation hostnames, or if the privacy of having a system wide service be able to intercept end-to-end encrypted services slightly before it reaches the intended client service is acceptable.

This was back in 2015-2017, but several AVs had known weaknesses when HTTPS scanning were enabled: How Kaspersky makes you vulnerable to the FREAK attack and other ways Antivirus software lowers your HTTPS security - Hanno's blog
Having a look at Kaspersky, I saw that it is vulnerable to the FREAK attack, a vulnerability in several TLS libraries that was found recently. Even worse: It seems this issue has been reported publicly in the Kaspersky Forums more than a month ago and it is not fixed yet. Please remember: Kaspersky enables the HTTPS interception by default for sites it considers as especially sensitive, for example banking web pages. Doing that with a known security issue is extremely irresponsible.

I also found a number of other issues. ESET doesn't support TLS 1.2 and therefore uses a less secure encryption algorithm. Avast and ESET don't support OCSP stapling. Kaspersky enables the insecure TLS compression feature that will make a user vulnerable to the CRIME attack. Both Avast and Kaspersky accept nonsensical parameters for Diffie Hellman key exchanges with a size of 8 bit. Avast is especially interesting because it bundles the Google Chrome browser. It installs a browser with advanced HTTPS features and lowers its security right away.

And that's what scares me a bit about SSL inspection. Some of these AV implementations used to be worse than the browser.
 

MacDefender

Level 14
Verified
Oct 13, 2019
643
I use Eset on my laptop and its HTTPS filter protects almost all web applications in my system, I also created a blacklist of popular trackers in it and as a result it blocks tracking even in some online games, so the HTTPS traffic filter is the main reason why I continue to use this product.
I should add, if you use ESET, I would say the HTTPS filter is almost a must. So many dynamic detections in the Malware Hub when ESET was tested was due to the internet traffic filter detecting a secondary malware payload that matched a signature. Everyone customizes their first stage injector to bypass signature detection but gets lazy with stage 2.

Other AV products tend to have dynamic behavior blocking and other techniques that provide sufficient protection against secondary downloaded malicious payloads, but ESET honestly has almost nothing.

If you disable ESET‘s HTTPS filtering, basically you lose all “dynamic” protection shown in the Malware Hub test, and at that point it’s basically just as effective as Google Chrome’s download screener.
 
Top