Antivirus Web/HTTP shields and HTTPS connections

Can anybody please clarify if HTTP shields/scanners in AVs (such as Webguard in Avira) provide any value over HTTPS streams?
I guess it is clear that they cannot scan the traffic content over an HTTPS connection (and is not port 80). Does it also bypass them with the use of VPNs, proxies, HTTPS everywhere addons etc. I am assuming so, though I am unclear where it is decrypted (E.G. via OpenVPN with VPNs) and if it is then seen by the scanner.

Might this make sense:
- Banking, shopping or anywhere personal information is exchanged, or if privacy is required - always use HTTPS links and also a VPN if in a public place
- General browsing - use HTTP links (turn off VPNs etc.) allowing AV http scanner to check for driveby downloads etc.

I know that the AV can always subsequently block files from drivebys when they are on the PC. So I am thinking that web/http scanners don't add much (in fact they usually slow down browsing) when using a lot of SSL tools/connections and it is better to focus on SSL communication and the other security layers?

 

Webguard is a transparent system proxy for HTTP. It doesn’t filter secured connections (HTTPS).

https://www.wilderssecurity.com/showpost.php?p=2167621&postcount=3

 

Additonal Information
Web Protection will filter all the non-decryption HTTP traffic through the port
80, 8080, 3128

 

Thanks, I was aware that it does not filter HTTPS traffic directly. My question was more does it provide any value where all communications are over an SSL link external to the browser. E.G. with a VPN which would not show as an HTTPS URL in the browser (for http web pages). Also browser add-ons are appearing that provide SSL links within the browser (E.G. Zenmate a VPN proxy add-on). So if I browse all the time with a VPN active is the http scanner redundant?

 

Sounds like you have already answered to your question. i.e. no value

 

AVs, etc can filter a browser's requests/responses sent over HTTP and HTTPS by installing and using a browser extension. They can also intercept traffic to create a local MITM. Which in the case of HTTPS would involve installing a CA certificate. So there would seem to be potential for an AV to intercept/filter browser traffic, including that which is bound to traverse a VPN connection. Where a browser extension isn't used, perhaps success would depend on how the VPN client captures/routes traffic and whether the AV's approach to MITMing it interferes.

I'm not aware of VPN clients supporting extensions. Conceptually, I suppose an AV program could install a system CA certificate and if the VPN client uses HTTPS and if it uses system certificates and if the AV redirects/intercepts the VPN client's traffic then the AV program could perform a local MITM of VPN traffic like some do with browser traffic. I don't know if any actually do this this though.

 

Interesting, I was thinking more of AVs that filter on port 80 and VPN browser extension such as Zenmate which I think uses a proxy within Chrome. I don't think using certificates is a viable general solution for an AV.

It seems that it confirms that the HTTP based web guards/shields/scanners are an unnecessary overhead if using an always on SSL solution such as a VPN.

 

Hello,

In ESET's software, SSL protocol scanning is not enabled by default. To toggle it on, go to Advanced Setup (F5 key) → Web and email → Protocol Filtering → SSL and you can review the various settings and context-sensitive online help from there.

The above example is for ESET Smart Security 7; settings/locations in other programs and versions may differ.

Regards,

Aryeh Goretsky

 

Not used ESET myself but it is interesting one provider has some support for SSL connections. However I guess it would only be able to check traffic from sites where it had some sort of certificate pre-enabled, which of course would only be from known secure sites (for SSL URLs which is not what I was interested in). But if it had a certificate for the SSL encryption provided by a the VPN connection then it would have value as it could filter the encrypted content from non-SSL HTTP sites (that are the ones likely to have malware).
N.B. excuse all the probable incorrect use of terminology above!

This has got quite deep but I am still a little concerned that the increase in using encrypted connections of various sorts (HTTPS, VPNs etc.) makes it difficult for security software to identify malware early in the communication process (not until it actually hits the disk of the PC).

 

ESET is not the only antivirus that can scan secured communications. However, enabling SSL scanning also has some drawbacks and some applications may not work correctly unless you exclude the appropriate certificate from scanning.

 

True, for example, Kaspersky can also scan https and yes it may not work for some applications

 

Avast for Mac does.

 

I thought there was a more elobarate thread here about SSL/HTTPS scanning through local MitM and the downsides, but I can't find it so I'll post here.
Using SSL scanning can actually degrade security. I'm not talking about the fact that you can't verify certificates because the browser only sees the AV certificate, but the connection is actually worse.
I tested Bitdefender TS 17.27.0.1146 with IE10 and FF28 on Windows 7 with SSL Labs client test.
Verification: With SSL scanning enabled I see a Bitdefender certificate in each browser instead of SSL Labs certificate and both browsers show the same altered results in the Client test instead of their own separate results.

Observations:
No TLS 1.1 and/or 1.2
No ECDHE ciphers(a lot of popular sites like Facebook only use ECDHE for Forward Secrecy, not DHE, so in these cases you will loses Forward Secrecy.)
It supports weak DES, RC2 and export ciphers
No OCSP stapling

 

I think, and please correct if I am wrong the impact is only local as connections need to be channeled into the proper SSL otherwise it would not be recognized or accepted. The only purpose of the certificate is to be able to read the encrypted information locally.

 

This is not local, it's about the connection between the server and Bitdefender, before BD decrypts the traffic to scan it.
When Bitdefender has scanned the traffic it encrypts it again for the browser to accept it yes, that is the local part.

 

Isn't it this also local? Or what you mean by "bitdefender" when you say " server and Bitdefender "?

 

Normally it's like this(Forgive my Paint skills ):

Then BD comes along:


So BD is doing the Man in the Middle locally on your PC, but because it is a MitM, the server is communicating with BD, not the browser. So BD negotiates the SSL/TLS connection and thus has control over what protocols and ciphers are used for the SSL traffic that passes through your WiFi, router, ISP, internet exchange point etc.
Because BD's SSL module doesn't support TLS 1.2 etc, they can't be used for that traffic.
The browser doesn't accept all this so BD has to re-encrypt the traffic to your browser, and to prevent certificate warnings, it has to install it's own Root CA in your browser first, so the browser will accept the certificate issued by Bitdefender and view it as legitimate.

So if I test this with the SSL Labs client test, SSL Labs is communicating with BD instead of my browser, so then I'm able to see what protocols and ciphers are supported by BD.

EDIT: I'm not actually sure about the browser not accepting part. It may be possible to do this without re-encrypting traffic to the browser, but that would mean users would never see lock icon in the browser and get confused, thus possibly hurting sales. So the AV vendor re-encrypts the traffic, and then the browser will object because the certificate used is not valid for the visited website. Because of that a Root CA is installed in the browser so the browser trusts the certificate.

If a potential attacker would want to to a MitM on you, he encounters the same.
-He doesn't re-encrypt, which means his target might get suspicious and doesn't enter any information on the site, attack failed.
-Or he somehow infects your computer to install a Root CA in your browser.
-Or he somehow gets a legitimate certificate, for example by hacking a CA and obtain the signing keys to sign his own certificates(example: Diginotar hack) or a Governmental agency forcing a CA through a court order(depending on laws of that country).

 

Thanks, makes sense... it would interesting to see if also Kaspersky follow the same approach and same weaknesses.

 

I just checked ESET Smart Security 7, it uses the same approach, but the security is a little better:

ESET:
Also no TLS 1.1 and/or 1.2
It does support ECDHE ciphers, though non forward secrecy ciphers are preferred
No weak ciphers
Also no OCSP stapling

The fact that the browser only sees the certificate from the AV got me thinking that the browser can't do verification of the website certificate, so the AV has to do that as well.
I checked both BD and ESET with the cloudflare-challenge test site, which has a revoked certificate, but there was no warning at all.

About Kaspersky, I've seen posts about certificate errors even after manually installing Root CA with Kaspersky, so that would mean it uses the MitM method as well.

 

So HTTPS checking should be disabled (as it is by default with ESET). Content transferred over HTTPS will be scanned by AV when it is written to disk...

hqsec

 

Yes, imo.
BD was on by default, I think.
It would also be possible to use a browser addon to scan traffic right after it has been decrypted, before it's actually loaded by the browser. Though that would mean it would only work for a browser the AV company developed an addon for, so if you use a less popular browser, it won't work for you. The AV company would have to develop and maintain the addons, which means extra costs, so I doubt it will be a much used method.
Also, all the AV browser addons I've seen are used for URL filtering, checkmarks next to search results, password managers etc. I haven't yet seen one that scans HTTPS traffic.

 

Kaspersky(KIS 14.0.0.4651(f)) has different results.
It seems the browser is partially used to negotiate the connection. The ciphers and supported TLS versions are still the same, and if I disable something in the browser settings, it shows in the results.
However the results at the bottom of the client test are changed:
TLS compression is enabled(vulnerable to CRIME attack)
OCSP stapling is supported with FF, not IE.
A lot more signature algorithms are supported.
A lot more elliptic curves are supported.

Overall, a lot better than BD and ESET, though the TLS compression is a pity.
And kudos to big K:

 

Excellent... thanks a lot for checking

 

Why AVAST scans no HTTPS connections?

 

Avast for Mac does in Web Shield and Mail Shield. I would only assume it would be that way in the PC version.