Eset Blocking Chromecast

[The Scorpion 1]

I have recently installed version 12.2.23.0 of Eset Security.

After installing it I could not connect with my Google Chromecast device.  ('no device found' error message when casting)

If I uninstall Eset I can connect no problem.

I contacted Chromecast and was told that I was the 4th person in the last few days to have experienced this problem when using Eset.

I've tried reinstalling Eset but the problem continues. So Eset may be a no go if there is no fix.

Is Eset aware of this and is there a fix for this?

Edited July 22, 2019 by The Scorpion
.

[Marcos 5,072]

Did you have an older version of ESET installed before and it worked? Does any of the following make a difference?

- temporarily disabling HIPS and rebooting the machine
- temporarily disabling real-time protection in the advanced setup and rebooting the machine
- temporarily disabling Device control in the advanced setup and rebooting the machine

[itman 1,659]

This sounds like an Eset firewall issue to me.

Open the Eset GUI. Select Network Protection. Click on the Troubleshooting Wizard and see if the Chomecast dongle connection is  shown as blocked. If so, click on the Allow tab and Eset will auto create firewall rules to allow the connection thereafter.

[The Scorpion 1]

Marcos, Itman, Thanks for replies.

I think the problem has started with the latest version.

Tried all the suggestions but the problem remains.

(Itman, the chromecast was not listed as blocked)

 

[Evtim 0]

Hi guys, I have the same issue. Installed 12.2.23.0 of Eset Security and cannot use chromecast. Thank you for your help

[itman 1,659]

i went through Google's Chromecast support web site documentation and noticed this:

Quote

For other anti-virus software, look for options related to SSL, TLS, or encrypted connection scanning. You might also try temporarily disabling or uninstalling anti-virus software to confirm that it is the source of the issue.

https://support.google.com/chromecast/answer/3249268?hl=en

Try temporarily disabling Eset's SSL/TLS protocol scanning and see if that resolves the connection issue.

[Evtim 0]

Thank you, Itman. Ignoring C:\Program Files (x86)\Google\Chrome\Application\chrome.exe under SSL/TLS filtered applications solved the issue for me. However, isnt't my computer exposed to threat now? thank you

Edited July 22, 2019 by Evtim

[The Scorpion 1]

Thanks for the input Itman. I've just disabled Eset's SSL/TLS protocol scanning Google\Chrome\Application\chrome.exe and my Chromecast is now recognised. ☺️

Looks like that may be the problem.

Is leaving this disabled likely to cause any problems or major vulnerabilities?

Edited July 23, 2019 by The Scorpion

[lamar 10]

Same issue at me. Disabling SSL/TLS protocol scanning might be a temporary solution, however ESET has to fix this bug, because users loose an important protection layer that cannot be disabled in a long term.

[Marcos 5,072]

3 hours ago, lamar said:

Same issue at me. Disabling SSL/TLS protocol scanning might be a temporary solution, however ESET has to fix this bug, because users loose an important protection layer that cannot be disabled in a long term.

It's probably not a bug but design of how SSL works. Let's try switching SSL filtering to interactive mode. When asked if you want to filter the Chromecast-related SSL communication, choose Exclude. Then you can switch back to automatic SSL filtering mode.

[The Scorpion 1]

I went into  'List of SSL/TLS filtered applications' 

selected C:\Program Files(86)\Google\Chrome\application\chrome.exe

and then selected 'ignore'.

[Marcos 5,072]

5 minutes ago, The Scorpion said:

I went into  'List of SSL/TLS filtered applications' 

selected C:\Program Files(86)\Google\Chrome\application\chrome.exe

and then selected 'ignore'.

If you use Chrome for browsing the Internet then the above will cause ESET to not scan any website you open or any file you download via the browser which will expose your computer at risk.

A much safer solution is to exclude just the specific certificate as suggested above.

[The Scorpion 1]

3 minutes ago, Marcos said:

If you use Chrome for browsing the Internet then the above will cause ESET to not scan any website you open or any file you download via the browser which will expose your computer at risk.

A much safer solution is to exclude just the specific certificate as suggested above.

Ok. Thanks

[The Scorpion 1]

5 hours ago, Marcos said:

Let's try switching SSL filtering to interactive mode. When asked if you want to filter the Chromecast-related SSL communication, choose Exclude. Then you can switch back to automatic SSL filtering mode.

I've selected 'interactive mode' but no filter queries ever come up for 'Chromecast' even when I select 'cast'.

There are dozens of 'google chrome' hits while on various sites but nothing mentioning chromecast ever appears.

Anyone know how to force a filter query for chromecast?

[lamar 10]

@Scorpion: Marcos is right . Putting chrome.exe itself to the exclusion list equals to disabling the entire SSL/TLS filtering service since browser generates 90% of the secured traffic for an average user.

@Marcos: I do not agree with you that it is not a bug. If a new phenomenon appears that did not exist before we can distinguish two ways. If it makes our life happier, it is a nice feature. If it makes our life confusing, it is an ugly bug. Therefore this behavior is an obvious bug from the point of view of the average user. I suppose that "grandma-next-door" will not be able to perform the "switch-to-interactive-then-switch-back" sequence for watching movies as before. I think ESET has to roll out an urgent and permanent solution.

[itman 1,659]

@Marcos refer to this bleepingcomputer.com where Kaspersky users are having the same issue: https://www.bleepingcomputer.com/news/security/kaspersky-av-having-certificate-conflicts-with-google-chromecast/ .

Appears Chromecast is using a self-signed cert., select IP addresses, and most importantly port 8009. I believe this might be related to my prior post where I noted that SSL/TLS protocol scanning was defaulting to scanning all ports.

Folks, as a test make sure Eset SSL/TLS protocol scanning only specifies port 443 for the HTTPS setting and see if the problem goes away. 

-EDIT- If you get an Eset "internal error" message when attempting to save your settings after the change to port 443 exclusively, ignore it. Eset will still perform the change. But, also verify later that only port 443 is shown.

Edited July 23, 2019 by itman

[lamar 10]

@Marcos: As Scorpion reported, the "switch-to-interactive-then-switch-back" sequence does not work. Same at me.

@itman: Thank you for the idea! I have been saving the XML files of the factory settings of ESET versions, and according to my archives up till V12.1 HTTPS filtering was limited to port "443" . Now I see the value "443, 0-65535" which is very strange since the leading "443" is totally redundant as "0-65535" covers the whole ports range. I am not sure it is a good idea to switch back to the "443-only" value as several other ports can perform SSL/TLS communication (eg: 8443), and this way they become unprotected. Instead, I suggest excluding only port 8009 that Chromecast uses with the exclusion value: "443, 0-8008, 8010-65535" (leading "443" is left for ESET-loyalty.)

However this is also a temporary solution. It is risky to exclude a single port for watching NETFLIX or HBO GO. Google and major AV/FW developers have to solve this problem.

[Marcos 5,072]

11 minutes ago, lamar said:

Now I see the value "443, 0-65535"...

Please keep only port 443 there. Somehow the range 0-65535 was added at some point in the past, I had it already in v12.1.

[itman 1,659]

38 minutes ago, Marcos said:

Please keep only port 443 there. Somehow the range 0-65535 was added at some point in the past, I had it already in v12.1.

I would say presently this is the best approach till Eset definitely resolves why this port range specification was added. And again, I informed about this previously and it appears no action was taken at that time.

Note that Windows internally sends encrypted data various ways other than by port 443 and it is likely that communication may silently being blocked.

One possibility is that the 0-65535 port range was added for non-HTTPS scanning use and Eset internally is erroneously using it instead for also HTTPS scanning.

Edited July 23, 2019 by itman

[lamar 10]

44 minutes ago, Marcos said:

Please keep only port 443 there. Somehow the range 0-65535 was added at some point in the past, I had it already in v12.1.

I do not think it is so easy. I have made two clean-installation tests in virtual environment.

for v12.2.23.0 the factory value is "443, 0-65535"

for v12.1.34.0 the factory value is "443" however after finishing the initial update I found it changed to "443, 0-65535"

(only definition updates, NOT program components. version is still 12.1)

There has to be a reason why Eset do this behavior. Very disappointing...

Edited July 23, 2019 by lamar

[itman 1,659]

4 minutes ago, lamar said:

or v12.1.34.0 the factory value is "443"

Not on my like ver. build. This is why I reported the status initially.

Ref.: https://forum.eset.com/topic/20040-ssltls-scanning-port-assignments/

Edited July 23, 2019 by itman

[itman 1,659]

I also just completed deleting all SSL/TLS protocol filtered apps and now letting Eset rebuild it on demand from a process requesting port 443 access. The prior list literally contained every app on my system that had ever performed an outbound network connection.

[lamar 10]

27 minutes ago, itman said:

Not on my like ver. build.

I made the clean install tests without activation to get the true factory values. After I activated the product it immediately started downloading the latest definition updates and the value changed to "443, 0-65535" with v12.1.34.0 as well. I suppose if I had installed it with an initial activation I would have got "443, 0-65535" as factory value due to the immediate updating.

[itman 1,659]

Following up on my prior posted "hunch" that 0-65535 is supposed to be used by HTTP protocol scanning only, refer to the below screen shot. Eset in-program help mentions "ports defined in Ports used by HTTP protocol" but no such setting exists in the GUI page for this. I believe it was supposed to be immediately below the HTTP protocol use setting option as shown by my drawn arrow mark.

Rather than properly fix the GUI page, it appears someone did a "band-aid" patch and threw this HTTP port range as an appended port range to the corresponding HTTPS ports used field, Then they didn't modify Eset's internal code to accommodate the misplaced HTTP port range resulting in it being used also by HTTPS protocol scanning.

In other words, we have reached a new unprecedented level of QC sloppiness.

Edited July 23, 2019 by itman

[lamar 10]

2 minutes ago, itman said:

In other words, we have reached a new unprecedented level of QC sloppiness.

May something go wrong with Eset? The first warning sign was they withdrew themselves from independent AV tests in December 2017. I am a persistent user since the early 2000's but nowadays question marks proliferate around my favorite AV/FW.