Unencrypted connections to google DNS servers and eset servers

[CNN 0]

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

[Marcos 5,259]

Updates are downloaded via http but files are digitally signed to prevent tampering.

Update and download servers are located in several countries around the globe; obviously some servers must be also in the US since it's a country with many ESET users and some of the update servers must be close to them.

Since you are from Europe, ESET should route the communication to the nearest servers instead of connecting to the US.

[CNN 0]

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?

[Marcos 5,259]

On 7/13/2021 at 8:10 PM, CNN said:

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?

Only the communication between ESET and the browser is re-encrypted after scanning the secured content.