amirr

Level 7
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
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
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
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
• 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
 

security123

Level 27
Verified
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
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 4
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.
 
Top