itman

You have to start reasoning out things on your own. It doesn't matter what the .exe is. It is obviously performing some Internet activity and doing so by proxy port means. As it stands right now, Eset's SSL/TLS protocol scanning will not allow that proxy activity to occur unless port exceptions are created.

You can also try to set Adguard_7.1.2817.0.exe to "Ignore" status in Eset's list of SSL/TLS filtered applications. I suspect why this didn't work for AdGuardSvc.exe is because it is actually running as a svchost.exe instance.

Makes sense. The prior screen shots you posted showed proxy ports used by AdGuardSvc.exe. Appears this process, Adguard_7.1.2817.0.exe, is using different ports. You will have to find out what those ports are and exclude those as well from Eset's HTTPS ports specification. Likewise, this same process will have to be repeated for any additional conflicting Adguard process. Also note that the more ports excluded from Eset's HTTPS ports specification, the higher the likelihood that that SSL/TLS MITM interception could occur.

I most certainly hope so. That will give you time to work on your spelling skills. As far as what the "truth" is, we haven't established that Eset is non-functional as evidenced by the absence of ekrn.exe running. All that is known at this point is that Eset's GUI interface is non-functional.

As @Rami noted and assuming you're running Win 10, Windows Defender would immediately engage if for some reason, Eset's real-time protection was non-functional. As such, you would still be protected from malware.

Open Windows Task Manager and verify if Eset Service is running. In Win 10, it should be listed as Eset Service (2). Click on it and two services will be shown; Windows Firewall Helper and Eset Service. Note that the Firewall Helper Service would only appear for EIS or ESS. NOD32 doesn't include the Eset firewall component. If the Eset Service is running, this indicates you're protected and the problem lies in the Eset GUI interface components.

See this thread: https://forum.eset.com/topic/20296-eset-internet-security-question/ . Appears Eset is presently clueless as to cause. Appears known affected parties have resolved it by installing an older ver. of Eset and then upgrading it to the most recent ver.. Personally, I believe there must be a better way. Try performing an Eset Repair installation first to see if it resolves the problem. Via Windows Control Panel -> Programs -> Programs and Features -> Uninstall a program, select your Eset installed software. Click "Next" tab when Eset Security Setup Wizard window appears. Select "Repair" option and then click on "Next" tab to proceed with the repair installation.

Microsoft added Tamper Protection in Win 10 1903. Oddly, it has to be manually enabled. I keep looking for a published bypass if it, but so far so good for Microsoft. It also appears to "have held its own" against the latest and greatest version of Trickbot which tried its darnedest to disable it: https://www.bleepingcomputer.com/news/security/new-trickbot-version-focuses-on-microsofts-windows-defender/ Such can not be said for MalwareBytes or Sophos.

One final comment and it's in regards to Adguard. You might want to ponder a bit why the software is redirecting HTTPS traffic to its servers to perform man-in-the-middle inspection. As such it can intercept all your HTTPS traffic, decrypt it, and use that data for whatever purpose it so desires. Everything operational about Adguard is Russian based except for its corporate address - Cyprus - and most of its servers - The Netherlands.

I know what's wrong. You entered 65635 instead of 65535 as I posted.

Make a sure blank exists after each of the comma's.

In that case, you have two choices: 1. Disable HTTPS scanning in Eset or only specify port 443 which would leave you vulnerable to like malware proxy port man-in-the middle activity. 2. Disable HTTPS scanning in Adguard or unistall it.

Here's my Eset installation after I made the change:

Ignore the screen popup about an internal error. What you coded is correct. Just click OK and the Cancel thereafter. Then go back to that setting and make sure it was updated.

That is a bit strange I must say that it didn't work. Try this then. Open Eset GUI and change ports used by HTTPS protocol from 443, 0-65535 to: 443, 0-7999, 8002-65635 This will exclude ports 8000 and 8001 which it appears Adguard is using based on your posted screen shots.

Did you try this? This is the preferred method to use if it works.

Actually, there is no reason to continue this approach since this is not the problem. For example, I can access where Adguard's filters on are stored on Github: https://github.com/AdguardTeam/FiltersRegistry in a browser w/o issue with Eset's SSL/TLS protocol scanning enabled. The issue again is Eset is blocking the port redirect proxy activity Adguard is performing to access the above web site. Try this. In Eset's list of SSL/TLS filtered applications, one or more Adguard .exe's should be listed. Change the Scan action setting for all listed Adguard .exe's to "Ignore." Now test to determine if filter lists are updating.

This won't work. What will work is if you exclude all IP addresses that Adguard uses from Eset SSL/TLS protocol scanning. Also have you tried to exclude the Adguard related .exe's from Eset SSL/TLS protocol scanning? This is a much easier way to exclude if it works.

Also as noted by another SSL checker web site: https://www.sslshopper.com/ssl-checker.html#hostname=https://www.one-key.gov.on.ca/iaalogin/IAALogin.jsp , there is nothing wrong with the way certificates are being chained.

Technically speaking, the web site was downgraded by ssllabs.com because it doesn't support Forward Secrecy: https://blog.qualys.com/ssllabs/2018/02/02/forward-secrecy-authenticated-encryption-and-robot-grading-update

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.