livegrid, protocol filtering, and https scanning

[chrcoluk 2]

Ok so multiple questions here.

 

For quite a while I have had protocol filtering disabled.  I still scan any written and executed files and emails.  But I always believed extra scanning on network traffic was redundant.

 

Anyway a few days ago I enabled protocol filtering, http and https scanning, and found out quickly why https scanning was problematic.

 

nod32 handles the connection to the server, and then the browser communicates with nod32, this has implications fot encryption security, as I have no idea e.g.

 

what cipher is used between ndo32 and the server

if revocation checks are been carried out.

is nod32 patched against ssl vulnerabilities such as crime, heartbleed, and beast.

does it work with key pinning.

 

note these 2 web pages.

 

https://www.eff.org/deeplinks/2015/02/dear-software-vendors-please-stop-trying-intercept-your-customers-encrypted

https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

 

I already know nod32 cannot handle HSTS, my own domain has HSTS activated, and firefox will refuse access to a HSTS server if the certificate doesn't match up, when it tries to access my domain and see's the nod32 cert it gets angry and I cannot browse my site.

 

So I currently don't scan https, however for now I have left http scanning enabled with no current ill affects.

 

My next issue I want to raise is about protocol filtering and livegrid.

 

I have always left livegrid on and assumed it was in use, but someone warned me on wilder's security, that livegrid does not work if protocol filtering is disabled, I see no reference to this in documentation so this needs clarifying for me please.

 

In the settings I see a couple of options for protocol filtering.

 

"integrate into system" - no idea what this does, but is it a on/off switch for livegrid use on file/email scanning?

"enable application protocol based filtering" - this is a on/off for network scanning of http/https/imap/pop/pops/imaps but is it required for livegrid feature to work?

 

Thanks

[Marcos 5,070]

1, Web and email protection is an essential protection layer because:

- it can block malicious urls regardless of whether malware is recognized or not. ESET uses extensive url blacklists to prevent users from infecting if malware at known locations mutates or changes to a different one.

- it uses stronger detection methods than file scanners

- it uses a larger Live Grid database than file scanners.

 

2, Of course, https scanning may be problematic with certain applications or websites; that's why it's not enabled by default. Security is not jeopardized; SSL and TLS up to 1.2 is supported and revocation checks are carried out. The code responsible for protocol filtering was not affected by known vulnerabilities. Key pinning doesn't work with ssl filtering enabled, however, to my best knowledge other vendors are having problems with this too. Since I'm not a programmer who knows all ins and outs of https scanning, I'm unable to comment on it any further at the moment.

 

Live Grid had been used only by web and email protection until recently so the remark on Wilders' was indeed true. Currently other scanners utilize Live Grid as well, however, only web and email protection can cover the most of new malware by Live Grid.

 

"integrate into system" - enables / disables loading of drivers responsible for protocol filtering

"enable application protocol based filtering" - enables / disables routing of http(s)/pop3(s)/imap(s) communication via ekrn

Enabling / disabling email or web protection effectively enables or disables scanning of the above mentioned communication routed via ekrn.

[rugk 397]

About the second article you linked we already had a topic here and there I showed that the statement with the AV certificates being not scanned is wrong (at least for ESET).

 

I already know nod32 cannot handle HSTS, my own domain has HSTS activated, and firefox will refuse access to a HSTS server if the certificate doesn't match up, when it tries to access my domain and see's the nod32 cert it gets angry and I cannot browse my site.

This sounds more like a certificate mismatch rather than something with HSTS. Can you explain it more in detail?

According to the article you linked HSTS isn't used by ESET.

 

[...] and revocation checks are carried out.

Really? Does ESET use OCSP stapling?

 

As for key pinning - yes it's a "known problem" and other vendors have also problems with it, but ESET could just implement it by itself. One could argue that this would even increase the security mechanism as HKPK is then used for all SSL/TLS connections - browser-independent.

 

 

@chrcoluk

However you have to decide whether you want to enable SSL scanning. Of course it's a "man-in-the-middling", but if you think ESETs implementation for checking HTTPS connections is secure enough and you want HTTPS connection to be scanned too then you can enable it.

As for protocol scanning generally I would highly recommend to leave this enabled as it's a major protection layer as @Marcos explained above.

Edited May 16, 2015 by rugk

[Marcos 5,070]

Really? Does ESET use OCSP stapling?

Yes, it does.

[chrcoluk 2]

Rugk HSTS status is sent by the server not the certificate.

if a client doesn't support HSTS and HSTS is enforced by the server problems occur.

 

Here is a copy and paste of the error but censoring my domain name as its a private domain.

 

This Connection is Untrusted
You have asked Firefox to connect securely to www.xxxx.com, but we can't confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.

 

HSTS will get more and more common as sites like sslabs downgrade the grading without HSTS support.

 

My question to marcos is why does the filescanner not use full capabilities?

 

Also check https://revoked.grc.com/ the test fails when I have https scanning enabled, but passes when the browser does the revocation check.

 

If you going to intercept https traffic you need to keep up to date with modern ssl security practices.

 

I think the way forward with v9 is to replace https scanning with a browser addon, only scan "after" the browser has decrypted the traffic.

 

Your statement is also confusing.  https scanning is off by default, but you have stated without it https browsing doesn't get full livegrid protection, also nod32 online knowledgebase tells people with ssl issues to disable https scanning to resolve them, but doesn't warn they lose proper livegrid protection by doing so.  This is a real problem that needs resolving.

Edited May 18, 2015 by chrcoluk

[chrcoluk 2]

Ok an update, I have now got HSTS working, it seems I had to enable the root certificate option with firefox closed.

 

However running ssllabs test and checking ciphers in use doesn't look good.

 

Firefox reports me using TLS 1.0 to view my site.  I don't know if that's the cipher used between nod32 and the browser or between nod32 and the website.

 

ssllabs reports no tls 1.2 support, apparently this is coming but seems to be taking its time?

ssllabs reports no OCSP STAPLING support

ssllabs reports no session ticket support

ssllabs reports rc4 ciphers been enabled

ssllabs reports sslv3 enabled

ssllabs reports none forward secrecy ciphers at top of preference list (bad)

 

I hope these get resolved soon, and as I said in another thread, I hope you give control of ciphers in the settings.

[rugk 397]

@chrcoluk

if a client doesn't support HSTS and HSTS is enforced by the server problems occur.

Well... no that's not correct. HSTS is just a HTTP header and clients which "know" it and can handle it do this the right way they can do it. (And Firefox of course supports HSTS)

The error you displayed may be based caused by the fact webserver now redirects you to http or otherwise the HTTPS connection failed. And now because of HSTS you are not allowed to skip this warning.

 

 

Your statement is also confusing.  https scanning is off by default, but you have stated without it https browsing doesn't get full livegrid protection, also nod32 online knowledgebase tells people with ssl issues to disable https scanning to resolve them, but doesn't warn they lose proper livegrid protection by doing so.  This is a real problem that needs resolving.

This was not exactly my statement. So let's go them one by one:

https scanning is off by default

Yes, that's correct.

but you have stated without it https browsing doesn't get full livegrid protection,

Not exactly. At first I didn't talked about ESET LiveGrid and as Marcos explained today ESET LiveGrid is used by more parts of the software so this is not directly connected to SSL scanning.

Secondly I didn't talked about "protection". I talked about the fact that the sites can't be scanned which is obviously if they can't be decrypted, so you have to decide if you think this makes your protection better or worse.

also nod32 online knowledgebase tells people with ssl issues to disable https scanning to resolve them

Yes I would tell you the same.

but doesn't warn they lose proper livegrid protection by doing so

Well that's not really needed as it's obviously too. If the scanning is disabled for a feature (which is SSL scanning and so only affects HTTPS sites) it of course doesn't scan the content, also not with methods like ESET LiveGrid. And no that's not really a big part of protection as LiveGrid (and other scanning methods of course) are still used for non-HTTPS connection.

 

Just keep one thing in mind (maybe you even confused this a bit here): Protocol scanning is something different than SSL scanning. You should always enable protocol scanning as it is just scanning all non-encrypted communication, which is of course not problematic, but is in fact a big protection layer (which also uses ESET LiveGrid of course)

 

If you going to intercept https traffic you need to keep up to date with modern ssl security practices.

Yes there I can fully agree. So ESET keep on HPKP and DANE or other features which are being introduced by some webservers already and may be get more later!

 

I think the way forward with v9 is to replace https scanning with a browser addon, only scan "after" the browser has decrypted the traffic.

Well this would be a safe possibility, however add-ons have other disadvantages (may be need quite fast updating, e.g.) so this is also not the ultimate solution.

 

Ok an update, I have now got HSTS working, it seems I had to enable the root certificate option with firefox closed.

Yes this seems to do something which the mode ESS/NOD32 uses to "inject" the SSL scanning root certificate into the Firefox root store. So yes you have to do this without closed browser. If you do it without closed browsers a message from ESS/NOD32 should be displayed that you need to close your browsers.

 

However running ssllabs test and checking ciphers in use doesn't look good.

 

Firefox reports me using TLS 1.0 to view my site.  I don't know if that's the cipher used between nod32 and the browser or between nod32 and the website.

 

ssllabs reports no tls 1.2 support, apparently this is coming but seems to be taking its time?

ssllabs reports no OCSP STAPLING support

ssllabs reports no session ticket support

ssllabs reports rc4 ciphers been enabled

ssllabs reports sslv3 enabled

ssllabs reports none forward secrecy ciphers at top of preference list (bad)

Well... that's strange, especially that many indicators there showing different things than Marcos said here SSL scanning would be enabled. On the other hand I don't know how these scans are performed by SSLLabs, but I still have no idea why they would show wrong results. Also it would be interesting to know whether ESS/NOD32 are vulnerable by the Logjam attack?

If they would have SSLv3 enabled this would be creepily bad, however I didn't think this was the case, but I've also suggested to add an option block all (also client communication) which is trying to use SSLv3, but didn't get any statement from ESET about this until now.

Edited May 29, 2015 by rugk

[chrcoluk 2]

Given all the other issues I am pretty sure it is also affected by logjam, but no browsers have patched logjam yet either, the only protection against logjam currently is to disable the suspect ciphers. (which nod32 gives no control over).

 

So I ask the question again.

 

If protocol scanning is enabled but http/https scanning is disabled.

 

Does file based scanning, email scanning etc. get livegrid cloud protection?

 

This is important because if the answer is yes, its not a big deal to disable https (or http) scanning as the content gets scanned when written to the browser cache folder anyway.

Edited June 4, 2015 by chrcoluk