itman

The reason the connection to this web site and others like it will failed is shown in the below ssllabs.com analysis screen shot. Note that the web site can employ two certificate pinning validation methods. Path 2 is specifically for detecting man-in-the-middle interception which of course what Eset is performing. It also appears that FireFox supports the Path 2 validation method whereas neither IE11 or Edge do.

The issue in this instance is not the fact that Eset SSL/TLS protocol scanning prevented a legitimate gov. web site from rendering in a browser although that is a concern. The primary issue is that Eset failed to display the proper alert as to why the communication was being blocked.

Someone using Chrome should also test using this web site. Believe there will be pinning issues with it as well.

Below is the cert. chain relationship in FireFox. Believe this is indeed a cert. pinning issue.

Per the below IE11 certificate chain screen shot, suspect the double root cert. setup is the issue. Firefox might handle this differently than browsers that use the Win root CA certificate store.

You mean itman to the rescue. Eset needs to definitely check this one out since everything about the cert. setup looks OK as evidenced by Firefox allowing the connection.

Yes. It is an Eset issue. Add this IP address, 204.41.16.53, to Excluded IP addresses in the Eset Protocol Filtering section. You should now be able to connect to the site in FireFox w/o issues. Looks like we found another Eset SSL/TLS protocol filtering bug ...........☹️

Does this mean that the HIPS now supports C:\somefolder\*.exe file creation monitoring?

One other thing your should check out if you use a WI-Fi network connection. That is not make sure that connection is properly configured on your router using the strongest encryption setting available. Given the cert. in question appears to be related to a game software developer, it is possible someone in your neighborhood might be a gamer and has figured out a way "to tap into" your WI-Fi connection.

I ran it on Win 10 x(64) 1809 w/o issue. Just make sure you select the option to "keep my files." Note that the screen shots given in the linked article are for Win 10 ver. 1903. The option settings for file retention are different in earlier Win 10 vers.. They use a check mark selection for file retention options. As I recollect, the option to keep all user personal files is check marked by default on the earlier vers.. When this option screen is displayed, just proceed carefully and verify the "keep all user files" option is selected. However since this a Microsoft feature, I take no personal responsibility if the feature doesn't work as intended.

Researching this a bit and using the cert. name, *.dev.rtsarenagame.com, as a clue, it appears this is a development certificate. You can read about what development certificates are here: https://smallstep.com/blog/step-v0-8-6-valid-HTTPS-certificates-for-dev-pre-prod.html The gist of the matter is development certificates are for internal use only. It is possible one of your apps had a borked update resulting in this certificate being used, etc.. I wouldn't worry about it unless Eset starts alerting about it again. What you can also do is to check if that cert. somehow got added to the Windows root CA certificate store using certmgr.msc.

The Github certificate is self-signed. Strongly suspect this is the same issue manifested in the Chromecast thread. Adguard must be performing some MITM port redirect activity to ports other than 443 and this is what Eset's SSL/TLS protocol scanning is hiccuping on. Present there are two solutions: 1. Only specify port 443 in SSL/TLS protocol scanning. 2. You will have to find out what ports Adguard is performing its proxy activities with and exclude those ports from the existing Eset SSL/TLS port 0-65535 specification. For example if Adguard is using ports 1010,1011, and 1012, the Eset SSL/TLS port specification should be: 443,0-1009,1013-65535. Note that this will only work if Adguard is using static proxy port assignment. If it changes ports dynamically, you're out of luck. I whole heartily expect many more posts like this for other apps.

I would suggest 443, 0-8008, 8010-65535. It appears the developer set the HTTPS scanning to initially trigger on port 443 and then check for any port directed MITM proxy activity on any other ports which BTW, is what this Eset modification is all about. This processing was initially borked and all processes were being detected and added to the list of SSL/TLS protocol scanned processes. Based on recent testing, it appears the all processes HTTPS scanning has been corrected. I am observing only processes listed that originally connected via port 443.

Based on the SFC scan findings, I would say a Win 10 reinstall is called for. The least painful way to do so is to use the "Reset" feature in Win 10 described in this article: https://www.laptopmag.com/articles/reset-windows-10-pc . This feature will allow you to keep all your personal files but all your Windows non-Store apps will have to be reinstalled including Eset. So if you have customized Eset settings, make sure you export those prior to performing the Win 10 Reset. Hopefully after the Reset installation is completed and Eset reinstalled, it will function normally. Also note that a Win 10 Reset does not modify any existing Win 10 account logon profiles. So if there are issues associated with those settings, they will persist after a Reset is performed.

Realized this might be misinterpreted. Based on what I have read, once the Media Router extension is enable in Chrome via use of the Chromecast casting feature, the extension remains permanently enabled. As such, you remain vulnerable to any attack misusing it.

You can running this command from admin level command prompt window: sfc /scannow When that completes if you are running Win 10, then run the following command: DISM /Online /Cleanup-Image /CheckHealth Ref.: https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image Note that both sfc and DISM will take a while to complete.

This would infer you are using NOD32 which does not contain a firewall.

From the bleepingcomputer.com link in regards to Kaspersky like issues I posted previously. Eset along with most VirusTotal AV vendors detect the Trojan. None from what I can tell, detect any of the malicious JavaScript's it uses. Bottom line - unless browser based Chromecast is used, the Chrome Media Router extension should remain in its default disabled state.

Whereas there is a way to export the self-signed cert. from their webmail site here: https://webmail.jpberlin.de/roundcube/ and import it into Eset's list of SSL/TLS known certificates, I don't know if it would work in regards to Eset's client e-mail scanning. Someone from Eset will to comment on this. I am assuming the webmail certificate is the same one their client e-mail servers are using.

What we really haven't talked about is the origin of the problem which is: Here's a detailed analysis of a recent malware that exploited Chrome Media Router: https://securelist.com/razy-in-search-of-cryptocurrency/89485/

I just came across an interesting Google posting related to Chromecast titled; Cannot cast content from a wired PC connected to same router as wifi to which chromecast 3 connected Of note is the last recommendation: https://support.google.com/chromecast/thread/4191235?hl=en As such, I don't expect a speedy resolution to this issue other than the Eset SSL/TLS protocol scanning HTTPS port 8009 exclusion.

Don't believe this is an Eset firewall issue. When I was on the Sage web site, I received multiple alerts from uBlock Origin filter on FireFox about adware/tracking activities on the web site. Post a screen shot on any alerts from Eset it is generating while on the Sage web site.

If the entire quoted reference is read, the only thing that fixed this for the OP was a reformat of the OS partition and a clean install of Win 10.

Although not directly related to this Eset Chromecast issue, it is imperative that one validate that ports 8008, 8009, and 8443 are not open on the WAN side of the router. Before you ignore this, read this Sophos article: https://nakedsecurity.sophos.com/2019/01/04/dont-fall-victim-to-the-chromecast-hackers-heres-what-to-do/

Do you have any games installed from RTS Arena?