Eset Blocking Chromecast

[lamar 10]

52 minutes ago, am_dew said:

while troublshooting, I tried "pausing" the ESET firewall and I was still not able to see my Chromecast device. 

For me, the first "accused" was also Eset. I switched both AV and FW off, tried restarting Chrome, but I encountered the same as you, Chromcast were not visible. Another big question mark... So I went away suspecting the OS and the drossy engineering software tools I use. I wasted a lot of time by exonerating Eset too early.

Edited July 25, 2019 by lamar

[lamar 10]

@am_dew OMG! This is the answer: switching both AV and FW off still leaves protocol checking enabled. Very strange... It cannot be disabled by the tray icon and even by the Eset console switches. You have to go into the "advanced setup" for disabling it. And of course, you have to restart Chrome, to take it effect.

Edited July 25, 2019 by lamar

[Posolsvetla 15]

In order to help us investigate this issue, please proceed as follows:

1. Enable Network protection advanced logging
2. Replicate the issue (i.e. try to connect to Chromecast device)
3. Disable Network protection advanced logging
4. Collect the logs using ELC
5. Send me the created logs via a PM

The more detailed guide can be found at https://support.eset.com/kb3186/

[itman 1,659]

16 hours ago, am_dew said:

On a a slightly off topic issue, while troublshooting, I tried "pausing" the ESET firewall and I was still not able to see my Chromecast device.  I thought doing that would completely bypass ESET?

The Eset firewall has nothing to do with this issue.

Eset's SSL/TLS protocol filtering is done within the Windows Filtering Platform (WFP) on Win 8.1/10 that functions at the network layer application level. For Win 7, Eset uses a network adapter NDIS mini-port filter driver instead of WFP.

The real problem here is Google initially created the Chromecast dongle to be attached to IoT devices; namely stand-alone TV's. As such, it only used a self-signed certificate instead of a properly signed certificate issued by an appropriate root certificate CA. I believe that if you open Chrome's root certificate CA store, this Google Chromecast self-signed certificate is present. If it wasn't present, Chrome would block the connection regardless of any third party SSL/TLS protocol scanning in place.

Edited July 25, 2019 by itman

[lamar 10]

21 hours ago, itman said:

At this point when you open the browser and use Chromecast, you should be able to do so without any Eset issues.

I had much hope of your proposal, unfortunately it does not work. If I set Eset SSL/TLS protocol scanning to Interactive mode, it does not raise any alerts or warnings during addressing Chromecast. There is nothing to learn for Eset. After switching back to automatic SSL/TLS and all-ports protocol scanning Chromcast disappears again.

[lamar 10]

6 hours ago, Posolsvetla said:

Send me the created logs via a PM

Done. Could you please share your investigation results.

[itman 1,659]

1 hour ago, lamar said:

I had much hope of your proposal, unfortunately it does not work. If I set Eset SSL/TLS protocol scanning to Interactive mode, it does not raise any alerts or warnings during addressing Chromecast. There is nothing to learn for Eset.

Try this instead.

Repeat the same procedure but leave SSL/TLS protocol scanning mode in Automatic.

Once the Chromecast connection is made I don't know if the Chrome browser window is still shown? We need it because you need to copy the URL shown for Chromecast. Copy the URL shown. Then do the following:

1. Open Eset GUI. Then Setup -> Internet Protection -> Web Access Protection -> Web and E-mail -> SSL/TLS.

2.  List of Known certificates -> Edit

3. Click on Add tab. Then the URL tab.

4. Paste the URL previously copied in the box shown. Click on the OK tab.

At this point, the Google self-signed cert. info. should have populated the Certificate name, issuer, and subject fields.

5. Change the Scan action setting to Ignore.

6. Click on the OK tab on that screen and every screen thereafter to save the cert. info..

Retest that you can now connect to Chromecast site w/o issues.

 

 

[lamar 10]

26 minutes ago, itman said:

Once the Chromecast connection is made I don't know if the Chrome browser window is still shown? We need it because you need to copy the URL shown for Chromecast. Copy the URL shown.

Unfortunately Chromecast has no web server running on.  There is no browser window (hypertext) data for Chromecast and there is no URL for Chromecast. Only a single IP address. If I copy the IP address into the URL field "List of Known certificates" Eset gives an error message that there is no certificate there. As I wrote before, I suppose the Chrome software  and the Chromecast device performs some sort of tricky hidden communication in the background using port 8009. This communication does not affect the contents of either the  display window or the address bar of the Chrome browser at all.

[itman 1,659]

50 minutes ago, lamar said:

There is no browser window (hypertext) data for Chromecast and there is no URL for Chromecast. Only a single IP address.

What is the IP address?

Edited July 25, 2019 by itman

[itman 1,659]

OK. "The light just came on" in my old and worn mind.

What needs to be done is to exclude the local network assigned IP address; i.e. 192.168.x.xxx, etc. for the Chromecast device from Eset SSL/TLS protocol scanning.

The Kaspersky article got me off track.

Edited July 25, 2019 by itman

[rsternap 1]

On 7/24/2019 at 12:02 PM, rsternap said:

Try the help page here under 'problem accessing a device on your network'

https://help.eset.com/ees/7/en-US/solving_problems_protocol_filtering.html

adding the chromecast ip address to the exclude list worked for me.

Find the address in google home app - tap the icon for your chromecast device, tap settings (gear symbol), scroll down to information

Itman,

Already suggested, don't forget to assign a static IP in your router

[itman 1,659]

27 minutes ago, rsternap said:

Itman,

Already suggested, don't forget to assign a static IP in your router

Sorry.

Saw it but as I posted, the Kaspersky article caused me "to put blinders" on to anything else.

Don't know if the static IP bit is necessary. My internal IP addresses served by my router are always the same.

-EDIT- I just reread the Kaspersky article and only now realize that IP address given were local network ones.🙄. This is what happens when you get "totally bent out of shape" as I was when it was confirmed Eset was performing protocol scanning on all ports by default.

Edited July 25, 2019 by itman

[lamar 10]

42 minutes ago, itman said:

Don't know if the static IP bit is necessary. My internal IP addresses served by my router are always the same.

Unfortunately Chromcast can not be set up with a static IP address, so you have to set up your router's DHCP server to always assign the same IP address for the specific device. As I encountered I can not rely on the "native" IP address reservation feature of any DHCP servers.  If I do not fix it, the IP address is exposed to be reassigned unexpectedly.

Summarizing the results. Two working methods we have: exclude either the IP address of the device or the 8009 port from the protection. Neither of these are real solutions, they are only temporary patches. I hope Eset will investigate the logs I sent, and will roll out an update soon that let Chromecast go without needing any user intervention.

I was very pleased to meet you.

[itman 1,659]

It appears that the Chromecast connection is established via a separate app which is installed as part of the Chrome browser extension installation. When a cast session is established by Chrome, I suspect it spawns this app as child/independant process. Using either Eset's network connections tool or another TCP/UDP network connection utility, this can be verified to be the case.

If the above assumption is correct, additional security can be had by creating Eset firewall rules that:

1. Only allowing inbound and outbound connections to the ports used by the app; i.e. TCP protocol and remote ports 8008, 8009, and 8443.

2. Blocking all other communication by the app.

Additionally if it is this app that is actually performing all the casting network activities, it could be excluded from SSL/TLS protocol scanning instead of the Chromecast dongle IP address. This would be a more secure way to do so. This would also eliminate @lamar issue.

 

Edited July 25, 2019 by itman

[lamar 10]

7 minutes ago, itman said:

Only allowing inbound and outbound connections to the ports used by the app; i.e. TCP protocol and remote ports 8008, 8009, and 8443

8008 is the official alternative to HTTP port 80, and 8443 is the official alternative for HTTPS port 443. As I encountered both of these do not produce any conflicts between Eset and Chromecast, assuming they are used at all.

The "child process" hypothesis again is a nice idea of you, I immediately went to Eset's network connections panel, but unfortunately only chrome.exe is shown up performing somewhat communication with <IP_of_my_Chromecast>:8009. Ports 8008 and 8443 are not touched at all.

[itman 1,659]

Well, I guess we have "come full circle" on this discussion. So let's summarize the options:

1. Local Chromecast dongle IP address exclusion. The Kaspersky article implies multiple addresses might be needed. Don't know fully what that is about but could imply router dynamic address assignment. Therefore static address assignment would be required as previously posted.

2. Exclude port 8009 from SSL/TLS protocol scanning. No qualms with this one since it wasn't being previously scanned. I also believe other ports might need exclusion but "time will tell" on that one.

My own thoughts on this issue is the whole subject of allowing an IoT device direct access to your PC. But that's another separate topic discussion.

A footnote comment. Eset has "opened Pandora's Box" in regards to future issues in regards to performing SSL/TLS scanning of all ports. I for one, will avoid assistance on any of those issues.

Edited July 25, 2019 by itman

[JCHeberle 0]

On 7/22/2019 at 11:36 PM, 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'.

I had the same problem.  My Chromecast Ultra would no longer be seen in the Google Chrome "Cast" list.  The device would not appear.  When I selected "ignore"--as stated above--it showed up and I could cast from Chrome again.  Isn't ESET somehow associated with Google Chrome?  I hope ESET will fix this and it doesn't open vulnerabilities for Chrome! 

[Blackbox88 2]

Damm i am happy i found this thread.

I tried a lot myself spent a lot of time talking to chromecast support, Videostream support unfortunatly nothing helped untill i did a full reinstall of Eset and Chrome.

After that it all worked and I was happy as i could be, untill a few days later after mine vacation I tried to stream my rafting trips using videostream and we were back to the old "cant find the device trouble"

Luckily with this thread there is new hope.

The on thing which is strange for me is that Chrome + Videostream (plugin for chrome) both don't see the device but when I use rendering from VLC media player it does see chromecast and works fine.

Maybe it is good to investigate for some one with more skills then me, how VLC and chromecast commincate.

They are able to commincate with all the SSL/TLS scanning on.

[lamar 10]

Gentlemen, I have just received a private message from an Eset employee, that investigating the logs I sent they localized the bug, and a fix will be rolled out soon. Until that, please use one of the temporary workarounds mentioned here in the forum thread.

[itman 1,659]

I forgot to add this important comment to my prior posted summary.

Again, refer to the issue Kaspersky users were having using Chromecast. In this instance, Kaspersky was throwing an error in regards to the self-signed certificate Chromecast uses. It was this observation that led to postings in this thread to exclude the certificate using provided Eset means. However in Eset's case, the Chromecast communication was being blocked outright. In other words, network communication was blocked prior to reaching the Chromecast web server. This clearly implies that there is a major issue with Eset SSL/TLS protocol filtering for any port usage other than 443.

A bit of background on AV vendor responsibility in regards to SSL/TLS protocol scanning. What is being done is man-in-the-middle decryption activity using the vendor's root certificate. Because of this, it is an absolute requirement that the AV vendor perform all the necessary security steps normally performed by the browser/app to validate the certificate used by the web site/server . Most important of these steps is that the vendor perform certificate chain validation for the used web site/server certificate to ensure the certificate chains to its issuing root certificate authority.

Obviously, none of the above noted validations are being performed for the Chromecast connection. As such it is reasonable to assume likewise for all other SSL/TLS communication other than that using port 443. Also at this point, I am suspect of any Eset SSL/TLS protocol scanning using port 443 that is not browser based.

Edited July 26, 2019 by itman

[am_dew 3]

👍

Thanks for submitting the log and the update!

5 hours ago, lamar said:

Gentlemen, I have just received a private message from an Eset employee, that investigating the logs I sent they localized the bug, and a fix will be rolled out soon. Until that, please use one of the temporary workarounds mentioned here in the forum thread.

Edited July 26, 2019 by am_dew

[itman 1,659]

8 hours ago, Blackbox88 said:

The on thing which is strange for me is that Chrome + Videostream (plugin for chrome) both don't see the device but when I use rendering from VLC media player it does see chromecast and works fine.

Check which ports VLC media player is using when a Chromecast session is active. My guess is its using port 443.

Also based on this: https://www.advanceddigital.com/blog/using-vlc-multicast-unicast-udp-streams/ , VLC media player can use UDP protocol. If so, it is assumed that Eset is only filtering TCP protocol connections.

Edited July 26, 2019 by itman

[lamar 10]

9 hours ago, JCHeberle said:

When I selected "ignore"--as stated above--it showed up and I could cast from Chrome again. 

Please do not do that, as it has been discussed here yet: 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. Please read the whole thread. It will be painful, but hopefully useful.

[Blackbox88 2]

2 hours ago, itman said:

Check which ports VLC media player is using when a Chromecast session is active. My guess is its using port 443.

Also based on this: https://www.advanceddigital.com/blog/using-vlc-multicast-unicast-udp-streams/ , VLC media player can use UDP protocol. If so, it is assumed that Eset is only filtering TCP protocol connections.

@itman how do i check which port it is using when redering with VLC to Chromecast?

[AnnaJuist 2]

8 hours ago, lamar said:

Gentlemen, I have just received a private message from an Eset employee, that investigating the logs I sent they localized the bug, and a fix will be rolled out soon. Until that, please use one of the temporary workarounds mentioned here in the forum thread.

Really??...I do so hope you are right. I have had ESET for several years now. AND I always use my Chromecast to watch movies on my TV. I am elderly and find it difficult to watch programs on my Tablet.

I hope ESET can fix the issue it has with blocking Chromecast, soon. Maybe by the next update?

 I am computer illiterate and do not understand all the "Port" things you fellows are talking about.