CNN

Thanks for the feedback. I will take a look at this. But it seemed to me that the connections and opening unencrypted http ports was contemporaneous to the requests to an encrypted https request of my own. This behaviour is not as usual for an connecting update server. Could it be the case that eset, after the threat check on an encrypted request, cant reencrypt (fake) some of the escrypted SSL certifacates by which its sending them on the unencrypted http way to complete the connection to the server or some of the third party plugs of them?

When i was checking up my port connections i became aware of some processes concerning eset Internet Security. -One of the connection is made to the remote address: 91.228.167.26 . on Port 80. The reverse dns look up results to the "um21.eset.com". - eset ekrn is using also the Process ID 0 to bypass the communication and using meanwhile the unencrypted http port 80 (TCP): Remote Address : 91.228.166.88 / Remote Host Name : um11.eset.com ASN Number : 50881 ASN Name: ESET, spol. s r.o. Location: United States (US) Remote Adress : 38.90.226.11 / Remote Host Name: 38-90-226-11.ptr.eset.com ASN Number : 50881 ASN Name: ESET, spol. s r.o. Location: United States (US) -I could observe that also the DNS Requests to the google DNS Servers are bypassed though the Process ID 0 unencrypted. Even the Windows doesn't has yet the encrypted DNS requests, this could may a issue towards to the some Linux systems. Furthermore they are some other privacy issues with eset. Some of this servers are located in USA and unfortunately not in Slovakia. And its known that the USA is not privacy friendly because of they domestic laws (e.g. the Patriot Act). Can someone confirm or reject the listed problems as well? Best regards