SSL Protocol Scanning + Chrome 40.x

[cvvorous 4]

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)

[rugk 397]

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

[cvvorous 4]

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

[rugk 397]

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

[cvvorous 4]

Yep, still borked w/pre-release updates enabled. Guess I'll just leave it disabled til the updated module is released.

[FrancoVP 0]

Same issue here

 

OS: Windows 8.1 x64

Internet protection module: 1165B (20141128) 

[Marcos 5,070]

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.

[rugk 397]

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

[Marcos 5,070]

Internet protection module 1167 is now available on pre-release servers. Please test it with this new module.

[cvvorous 4]

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

[Marcos 5,070]

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.

[User 13]

Hmm, I have windows 7 SP1 64 bit and on pre-release servers, but still have 1165B.

[cvvorous 4]

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

[Marcos 5,070]

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.

[cvvorous 4]

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

[Utini 1]

So it is the best solution to disable SSL protocol filtering? Is it that much broken? :/

[cvvorous 4]

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.

[cvvorous 4]

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.

[rugk 397]

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

[Marcos 5,070]

Could you please open "chrome://version/" in Chrome and post all information except Variations here?

[cvvorous 4]

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

[cvvorous 4]

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

[rugk 397]

Well you didn't mentioned that you have tried it with this parameter...

[cvvorous 4]

fair enough

[rugk 397]

And? Has this parameter affected the issue?