Jump to content

itman

Most Valued Members
  • Posts

    12,200
  • Joined

  • Last visited

  • Days Won

    321

Posts posted by itman

  1. 28 minutes ago, am_dew said:

    I tried the various temporary fixes on three different computers....two worked and one did not and it is on the same network as one of the computers where the fix worked.  So, to take ESET out of the picture, I uninstalled ESET on the one where it did not work and I am still unable to use Chromecast, so there is something wrong outside of ESET on one of my PCs.  I'm not looking for answers to that issue here, however...just wanted to throw it out there.

    On the device where Chromcast connectivity cannot be established, Set HTTPS port to only 443 and see if connectivity is now established.

  2. 8 hours ago, Marcos said:

    if you make a relatively safe exclusion now you won't have to wait for the exclusion added via an automatic module update.

    Care to elaborate on how this can be done?

    Posters in the thread have tried to do just this using Eset's interactive SSL/TLS protocol scanning certificate exclusion methods. They have failed. The problem is that Eset is blocking the connection to the Chromecast dongle device. As such, the certificate on that device cannot be accessed.

    The only way this can be done would be to export the Chromecast certificate from the dongle device and import it into Eset using SSL/TLS protocol scanning certificate exclusion. The question is how can the certificate export from the Chromecast dongle be performed. -EDIT- It is also doubtful this would work. Unlike in Kaspersky where this issue presented as a certificate issue, Eset is blocking the connection prior to this event.

  3. I don't know if the following still applies. If is does, it doesn't bode well for Eset's SSL/TLS protocol scanning:

    Quote

    Answer to the first part of the question is Yes. Chromecast uses a PKI to secure communication. When Chromecast receiver app makes a secure http request (HTTPS/TLS), it is encrypted with a chromecast specific private key certificate (Which leads to Google). A server can use google's public key to decrypt the message and also extract information from the certificate if needed. This also means that you may not want to terminate the TLS on a load balancer and instead need the app server to do that. App server can store the google's public key and use it to decrypt it. There is a document which gives the details on how to decrypt and parse the certificate and what it has. I think if you have a developer account, you can get it.

    https://stackoverflow.com/questions/27146081/does-chromecast-come-with-a-certificate-bundle-allowing-simple-webserver-authent

  4. 54 minutes ago, Blackbox88 said:

    It seems to be using 8010:

    No. It's using a local proxy connection it appears to me.

    It listens for connections on local device port 8010. It then proxies the inbound traffic to the Chromecast dongle via port 8009. For outbound connections, the reverse occurs.

    The proxy activity bypasses Esets protocol filtering. Hence, why there is no issue with the VLC app.

  5. 25 minutes ago, AnnaJuist said:

    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.

    Are you stating you are now having problems with your Chromecast TV connection? This all ports protocol scanning issue should not be affecting that.

  6. 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.

  7. 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.

  8. The message you are receiving from FireFox is one of its own block messages. If you are seeing like behavior in other browsers, I would say it is a clear indication that something malicious is being hosted on that web site.

    I believe the only reason I could access the site was uBlock filtered out all the objectionable material on the web site prior to it being rendered in FireFox.

    Refer to my screen shot. Note the yellow triangle on top of the lock symbol. This is FireFox's indicator that secure content was blocked from being displayed; i.e. uBlock resultant activity.

  9. 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.

  10. I can connect to the web site fine as noted by the below screen shot using Win 10 x(64) Home 1903 and EIS ver. 12.2.23.

    Do note I use both uBlock and Decentaleyes and both are blocking a number of things on that web page.

    Since you installed Win 10 Pro, the issue might be you somehow activated some default Group Policy template by mistake.

    Eset_Page.thumb.png.fefb076be9ebfae6d4976fbb5eca023d.png

     

  11. 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.

     

  12. 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.

  13. 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.

     

     

  14. On 7/25/2019 at 11:17 AM, Rami said:

    So I did understand that the BIOS is very old and should be updated , so I went to Dell website and downloaded the latest BIOS which is July 2019 , I have flashed the up-to date BIOS , and I scan again , ESET still detects the CompuTrace

    Can anyone explain to me more about the CompuTrace ?

    CompuTrace on Dell PCs can be disabled via BIOS/UEFI setting. Since you just updated your UEFI? the setting might now be called "Absolute." Refer to this Dell article: https://www.dell.com/support/article/us/en/04/sln316123/computrace-replaced-by-absolute-module-in-newest-bios-revisions?lang=en and other related articles on the Dell support web site.

    BTW - old hardware only use a BIOS. Newer hardware contain both a BIOS and UEFI. Lojax and like malware only affect the UEFI.

    -EDIT- Eset's classification of Computrace is correct. It is a potential unwanted application as contrast to Lojax which is malware.

     

  15. 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.

  16. I reviewed your original posting. It appears your issue has nothing to do with Eset.

    To get Chrome to trust a self-signed certificate, it must be:

    1. Installed properly into Chrome. Details on how to do that are here: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/ .

    2. The self-signed certificate must be properly formatted.

    Based on the Chrome message you showed in the original posting, it appears your self-signed certificate is not properly formatted:

    ERR_SSL_SERVER_CERT_BAD_FORMAT 

    Additionally, it may be necessary to exclude your self-signed certificates from Eset's SSL/TLS protocol scanning.

  17. 1 hour ago, lamar said:

    Set the "ports used by HTTPS" field to "0-8008, 8010-65535".

    The problem with this if you "buy into" Eset's concept of scanning all port traffic is if malicious site uses port 8009, the incoming network traffic won't be scanned. Again this assumes if scanned, Eset would be able to detect the malware.

    Refer to the bleepingcomputer.com prior posted link on how the Kaspersky's Chromecast SSL/TLS protocol scanning exclusion was created. Only IP addresses associated with Chromecast were allowed to use port 8009. This is problematic in that Chrome could change existing IP addresses or use new ones. Also note that Eset's SSL/TLS protocol scanning does not have this capability.

    The only present secure way to do the Chomecast exclusion in Eset is to do the following:

    1. Only enable HTTPS scanning for port 443.

    2. Open you browser and don't do anything else.

    3. Set Eset SSL/TLS protocol scanning to Interactive mode.

    4. Navigate to the Chromecast web site via use of its extension/plug-in within your browser. Eset's SSL/TLS protocol scanning should throw an alert prompting "Scan" or Ignore." Select "Ignore." This should save the Google self-signed certificate in Eset's  SSL/TLS protocol scanning "List of known certificates" with its status set to ""Ignore." Verify that the certificate created is indeed Google's self-signed certificate.

    5. Close your browser and set Eset SSL/TLS protocol scanning to Automatic mode.

    At this point when you open the browser and use Chromecast, you should be able to do so without any Eset issues. If this is the case, you can reset Eset HTTPS port scanning to default values; i.e. 443, 0-65535 . If you're a non-technical user and what I just posted sounds like "a nightmare from hell" procedure, I agree with you 100%.

×
×
  • Create New...