livegrid, protocol filtering, and https scanning in ESET NOD32 Antivirus Posted May 29, 2015 · Edited May 29, 2015 by rugk @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.