cvvorous 4 Posted February 1, 2015 Share Posted February 1, 2015 Hi, I enabled SSL protocol scanning support and my primary browser (Chrome 40.x), but with it enabled, HTTPS-enabled sites regularly won't load. I tried rebooting my PC to see if that would fix it, but still had no luck. If I exclude the browser from protocol scanning altogether or disable SSL protocol scanning in ESS, it works fine. The second it's reenabled and the browser is restarted, it'll interfere with loading sites via HTTPS. I disabled the "block SSLv2" option in ESS because it broke the google drive sync client) Thanks OS: Windows 8.1 x64 Virus signature database: 11107 (20150201) Rapid Response module: 5452 (20150201) Update module: 1056 (20150113) Antivirus and antispyware scanner module: 1449 (20150116) Advanced heuristics module: 1153 (20140915) Archive support module: 1216 (20141127) Cleaner module: 1104 (20141205) Anti-Stealth support module: 1068 (20141218) Personal firewall module: 1259 (20141219) Antispam module: 1029 (20141103) ESET SysInspector module: 1245 (20141028) Real-time file system protection module: 1009 (20130301) Translation support module: 1273 (20141008) HIPS support module: 1159 (20150120) Internet protection module: 1165B (20141128) Web content filter module: 1036 (20140625) Advanced antispam module: 2045 (20150130) Database module: 1061 (20141124) Link to comment Share on other sites More sharing options...
rugk 397 Posted February 2, 2015 Share Posted February 2, 2015 (edited) About your main issue: Have you tried disabling SSL scanning, closing all browsers (or other applications which are using SSL connections) and re-enabling SSL scanning. Do you have the checkbox for "adding the certificate to well-known browsers" (or similar) checked? I disabled the "block SSLv2" option in ESS because it broke the google drive sync client) And that's a really strange thing, because I highly doubt that Google Drive would be using SSL v2. Does ESS shows any (SSL-related) message when it blocks this? Edited February 2, 2015 by rugk Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 2, 2015 Author Share Posted February 2, 2015 (edited) About your main issue: Have you tried disabling SSL scanning, closing all browsers (or other applications which are using SSL connections) and re-enabling SSL scanning. Do you have the checkbox for "adding the certificate to well-known browsers" (or similar) checked? I disabled the "block SSLv2" option in ESS because it broke the google drive sync client) And that's a really strange thing, because I highly doubt that Google Drive would be using SSL v2. Does ESS shows any (SSL-related) message when it blocks this? Hi, Yes, I've tried all of the following: - With all browsers closed, enable SSL protocol scanning. Stuff randomly fails to connect via SSL in Chrome. - With all browsers closed, enable SSL protocol scanning and reboot. After booting, stuff randomly fails to connect via SSL in Chrome. - With all browsers closed, disable SSL protocol scanning, reboot, re-enable it with browsers closed. Same issue. The error message in Chrome is: ERR_CONTENT_DECODING_FAILED - it seems as if ESS is mangling SSL content and causing Chrome to error out. Re: the root certificate, it defaults to add it when you enable SSL protocol scanning, so that's how it's set. Add root cert, ask about validity and block on invalid/corrupt cert. Re: the drive client, it doesn't display any error messages or anything else. Drive just says it's unable to connect (even after rebooting) when SSL protocol scanning is enabled. If I turn it off, it immediately connects without error. With drive: Any of the combinations of actions listed above for enabling SSL scanning, including the "block SSLv2" option --> drive won't connect. Uncheck "block SSLv2" drive instantly connects. *EDIT* forgot to mention I also raised log verbosity to diagnostic to see if there was anything showing up in product logs when I experienced the issue with Chrome, but the only odd thing I saw was "ESET Live Grid request failed because of authentication" Thanks Edited February 2, 2015 by cvvorous Link to comment Share on other sites More sharing options...
rugk 397 Posted February 3, 2015 Share Posted February 3, 2015 (edited) Even ESET LiveGrid is affected... I don't know if a SSL connection is used for ESET LiveGrid (but I hope so ), so does this issue with ESET LiveGrid also occurs when SSL scanning is disabled? But based on the error message of Chrome (ERR_CONTENT_DECODING_FAILED) I could find something in this forum. And I think they're about the same issue.It was reported two times: Google Search on Chrome Part of Web Site Blocked In the last post there is even mentioned that this will be fixed in the "next Internet protection module (probably 1167B)".But AFAIK this module wasn't released until now - even not in the pre-released state. However it's of course worth a try, so can you temporarily switch to pre-release updates and check if the issue remains? Edited March 1, 2015 by rugk Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 3, 2015 Author Share Posted February 3, 2015 Yep, still borked w/pre-release updates enabled. Guess I'll just leave it disabled til the updated module is released. Link to comment Share on other sites More sharing options...
FrancoVP 0 Posted February 3, 2015 Share Posted February 3, 2015 Same issue here OS: Windows 8.1 x64 Internet protection module: 1165B (20141128) Link to comment Share on other sites More sharing options...
Administrators Marcos 4,703 Posted February 4, 2015 Administrators Share Posted February 4, 2015 Using Chrome version 40.0.2214.94 m on Windows 7 x64 with Internet protection module 1165B, no issues noticed while visiting various HTTPS-enabled websites. I'm willing to connect remotely and check it out myself. Link to comment Share on other sites More sharing options...
rugk 397 Posted February 4, 2015 Share Posted February 4, 2015 (edited) Okay, maybe the planned module update also has nothing to do with this, because when I visit the site mentioned in the second thread I linked with Firefox it also displays the same error. So maybe this thing with Chrome wouldn't be fixed with the new module update - but as we can't test it actually of course I can't promise anything. Windows 7 x64 Firefox v 35.0.1 ESS v 8.0.304.x Internet protection module: 1165B (20141128) Edited February 4, 2015 by rugk Link to comment Share on other sites More sharing options...
Administrators Marcos 4,703 Posted February 4, 2015 Administrators Share Posted February 4, 2015 Internet protection module 1167 is now available on pre-release servers. Please test it with this new module. Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 4, 2015 Author Share Posted February 4, 2015 (edited) Using Chrome version 40.0.2214.94 m on Windows 7 x64 with Internet protection module 1165B, no issues noticed while visiting various HTTPS-enabled websites. I'm willing to connect remotely and check it out myself. chrome_ssl.png Would the OS version have any impact on whether you'd be having issues? Both FrancoVP and I are on Windows 8.1 x64, not Win7. Internet protection module 1167 is now available on pre-release servers. Please test it with this new module. I've enabled pre-release updates and I'm updating now. I'll let you know if I still see the issue in question. *EDIT* I enabled pre-release updates and performed an update within the product UI and rebooted after. The signature version is showing 11123P, but I didn't receive a new internet protection module (still on Internet protection module: 1165B (20141128)). Did I need to do something else, aside from enabling pre-release updates in ESS? Also, I think I figured out a way to cause the decoding error w/SSL filtering enabled- go to google.com in Chrome Begin typing a query in the search box on the site. Instant should immediately attempt to display search results. In my case, I get an error about instant being unavailable. If I then press enter or click the search icon, I get the decoding error immediately. Edited February 4, 2015 by cvvorous Link to comment Share on other sites More sharing options...
Administrators Marcos 4,703 Posted February 5, 2015 Administrators Share Posted February 5, 2015 Ok, there was a little misunderstanding and confusion. Module 1167 was released on pre-release servers for other than v8 users. V8 users have a module with a new http analyzer (indicated by B after the version number). I'll provide you with instructions how to install the latest version (1171B) manually soon. Link to comment Share on other sites More sharing options...
User 11 Posted February 5, 2015 Share Posted February 5, 2015 Hmm, I have windows 7 SP1 64 bit and on pre-release servers, but still have 1165B. Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 5, 2015 Author Share Posted February 5, 2015 Ok, there was a little misunderstanding and confusion. Module 1167 was released on pre-release servers for other than v8 users. V8 users have a module with a new http analyzer (indicated by B after the version number). I'll provide you with instructions how to install the latest version (1171B) manually soon. Thanks Link to comment Share on other sites More sharing options...
Administrators Marcos 4,703 Posted February 5, 2015 Administrators Share Posted February 5, 2015 To install Internet protection module 1171B, carry on as follows: - download the new module from here and save it to the disk - start Windows in safe mode - back up the original module C:\Program Files\ESET\ESET Smart Security\em019_32.dat and copy the new one instead - start Windows in normal mode - try to reproduce the issue - let us know about your findings. Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 5, 2015 Author Share Posted February 5, 2015 (edited) To install Internet protection module 1171B, carry on as follows: - download the new module from here and save it to the disk - start Windows in safe mode - back up the original module C:\Program Files\ESET\ESET Smart Security\em019_32.dat and copy the new one instead - start Windows in normal mode - try to reproduce the issue - let us know about your findings. Hi, I installed the new module and confirmed it via the "About" menu. I'm still experiencing the issue with content decoding errors and google search. At this point, I think I'll just give up on enabling SSL protocol filtering. It seems like this issue is an ongoing thing (threads on this board and others, including posts dating back to Chrome 33.x with the same issue when SSL filtering is enabled in ESS). I know doing things to SSL traffic can cause weird stuff to happen. Thanks for the assistance. Edited February 5, 2015 by cvvorous Link to comment Share on other sites More sharing options...
Utini 1 Posted February 10, 2015 Share Posted February 10, 2015 So it is the best solution to disable SSL protocol filtering? Is it that much broken? :/ Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 10, 2015 Author Share Posted February 10, 2015 So it is the best solution to disable SSL protocol filtering? Is it that much broken? :/ It was for me. The alternative is to exclude chrome from protocol filtering altogether, which I don't think is an acceptable solution. I don't really think disabling SSL filtering is all that great either, but as I mentioned, doing "stuff" to SSL traffic can cause issues, so I'm not upset about it. Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 21, 2015 Author Share Posted February 21, 2015 I might have nailed down what causes this. It seems to be related to google's use of SDCH protocol. Google doesn't advertise SDCH on the first query, but will on subsequent search queries. I'm guessing this is why I can typically manage one search before I start getting content decoding errors. To test, I set up a local proxy and had it scrub out SDCH from "Accept-Encoding" headers, and that seems to have fixed the issue, however, it's not really a permanent solution. There's supposedly a Chrome command line flag that should only allow SDCH on domains set by the flag (e.g. --enable-sdch=eset.com), but it doesn't work. Link to comment Share on other sites More sharing options...
rugk 397 Posted February 22, 2015 Share Posted February 22, 2015 (edited) Yeah, this could be the reason and could explain why it only happens with Google Chrome. So thanks for this good troubleshooting. Wikipedia article (HTTP compression): Additionally, third parties develop new methods and include them in their products, for example the Google Shared Dictionary Compression Over HTTP (SDCH) scheme implemented in the Google Chrome browser and used on Google servers. https://en.wikipedia.org/wiki/HTTP_compression It seems as this were also a bug in Privoxy (a proxy which also filters web traffic) and it was caused by a problem how it handles HTTP compressions. This could be a similar problem in ESS too. About the commando line parameter of Chrome: Normally it should work. Can you try it with --enable-sdch=never_enabled_sdch_for_any_domain? Edited March 1, 2015 by rugk Link to comment Share on other sites More sharing options...
Administrators Marcos 4,703 Posted February 23, 2015 Administrators Share Posted February 23, 2015 Could you please open "chrome://version/" in Chrome and post all information except Variations here? Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 23, 2015 Author Share Posted February 23, 2015 Sure: Google Chrome 40.0.2214.115 (Official Build) m Revision 831713c5c90271926c2ca70afaa969d32e4576f5-refs/branch-heads/2214@{#490} OS Windows Blink 537.36 (@189787) JavaScript V8 3.30.33.16 Flash 16.0.0.305 User Agent Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --no-startup-window --flag-switches-begin --disable-quic --manual-enhanced-bookmarks --flag-switches-end Executable Path C:\Program Files (x86)\Google\Chrome\Application\chrome.exe Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 23, 2015 Author Share Posted February 23, 2015 Yeah, this could be the reason and could explain why it only happens with Google Chrome. So thanks for this good troubleshooting. Wikipedia article (HTTP compression): Additionally, third parties develop new methods and include them in their products, for example the Google Shared Dictionary Compression Over HTTP (SDCH) scheme implemented in the Google Chrome browser and used on Google servers. https://en.wikipedia.org/wiki/HTTP_compression It seems as this were also bug in Privoxy (a proxy which also filters web traffic) and as it was caused by a problem how it handles HTTP compressions. This could be a similar problem in ESS too. About the commando line parameter of Chrome: Normally it should work. Can you try it with --enable-sdch=never_enabled_sdch_for_any_domain? I mentioned I already tried the switch and it didn't change anything Link to comment Share on other sites More sharing options...
rugk 397 Posted February 23, 2015 Share Posted February 23, 2015 Well you didn't mentioned that you have tried it with this parameter... Link to comment Share on other sites More sharing options...
cvvorous 4 Posted February 23, 2015 Author Share Posted February 23, 2015 fair enough Link to comment Share on other sites More sharing options...
rugk 397 Posted March 1, 2015 Share Posted March 1, 2015 And? Has this parameter affected the issue? Link to comment Share on other sites More sharing options...
Recommended Posts