ESET products version 10, try to connect all the sites that I visit.

[roler 0]

Hello.

 

Why ESET products version 10 are trying to connect to the same site where I go to the browser? In previous versions, it was nothing like this. I have long noticed that with each new version, you are more and more violating the user's privacy.

[Marcos 5,070]

ESET does not connect to the sites you visit. How do you know? What operating system do you use? On Windows XP, ekrn.exe acts as a local proxy through which all http communication is routed. As a result. you would see ekrn.exe connecting to the Internet instead of particular applications (e.g. browsers). It has worked that way for ages.

 

Do you observe this both with https and http websites or only with https?

[itman 1,659]

I have seen the same on both  Win 7 and 10. For example, my home page is att.yahoo.com. It is quite common to see ekrn.exe connecting to one or more yahoo.com domains associated with the home page. It usually does this upon first access to the home page but not on subsequent accesses to the page in the same browsing session. Also for any IPv6 connection, it is quite common to see ekrn.exe connecting to Akamai servers.  

 

I suspect the above connections have something to do with cert. validation for embedded HTTPS domains on the current web page due to SSL protocol scanning?

[roler 0]

ESET does not connect to the sites you visit. How do you know? What operating system do you use? On Windows XP, ekrn.exe acts as a local proxy through which all http communication is routed. As a result. you would see ekrn.exe connecting to the Internet instead of particular applications (e.g. browsers). It has worked that way for ages.

 

Do you observe this both with https and http websites or only with https?

 

Windows 10. Both.

I've never seen in other versions. I installed version 9 again. Everything is fine. As soon install 10 version of my third-party firewall is blocking the connection ekrn.exe to sites that I open in the browser.

​

 

hxxp://piccy.info/view3/10440135/4dd62589286be7364d6dc724d719ee9f/

Edited October 26, 2016 by roler

[itman 1,659]

Here also is a screen shot of what I was referring to in my previous reply. Also this is not unique to ver. 10. I have seen same activity on ver. 8 and 9.

 

Edited October 26, 2016 by itman

[roler 0]

I've NEVER seen this in other versions. The tenth version is clearly weaker than the other. The firewall does not work until you enter an activation key. Firewall skips connection when the computer starts. The window "Network Connections" almost empty. Many options in the "Tools" hidden. A long time is updated if you leave for a one specific server for updates.

[Marcos 5,070]

@itman: This was explained by MMX in another topic:

 

There are two reasons ekrn.exe might make connections to servers that are not operated by ESET if you have TLS filtering enabled. First when a browser tries to establish a TLS connection, ESET Security needs to decide if it will filter, block or leave the connection untouched. This decision is in part based on the certificate the server would present if the connection was to proceed, which is not available yet. To solve this problem, ekrn.exe opens a separate connection and requests the certificate, which allows it to make the right decision in the main connection. This certificate is then cached so that the extra connection is not needed later which minimizes performance impact. Doing this is necessary to implement certificate exclusions (e.g. F5 -> Web and email -> SSL/TLS -> Exclude communication with trusted domains, or storing a certificate with Access set to Allow or Block).

 

Second reason is related to the fact that ESET Security needs to verify the validity of the certificate presented by the server. Online communication is a regular part of such verification (see https://en.wikipedia...Status_Protocol). Doing this is necessary to make sure that no attacker hijacked the connection in transit since your browser won't see the original certificate.

 

Please note that in both cases ekrn.exe sends only what a browser would send if ESET Security was not installed. In a way ekrn.exe acts on behalf of the browser. You can verify this by capturing the communication using wireshark and analyzing it (the initial part of TLS connection that ekrn.exe does in case 1 is not encrypted, and OCSP is not encrypted at all since it relies on digital signatures).

[Marcos 5,070]

The firewall does not work until you enter an activation key.

 

I don't see anything wrong with that a program doesn't start working before activation.

 

Firewall skips connection when the computer starts.

 

How did you find this out? Both ekrn.exe and the epfwwfp driver are loaded among the first so any communication should be filtered since then.

 

The window "Network Connections" almost empty.

 

I was unable to reproduce it when comparing v8 and v10. Do you mean that if you open a website in a browser this connection doesn't appear there?

 

Many options in the "Tools" hidden.

 

There should be no difference compared to v9. Since new tools have been added, some had to be made accessible via "Other tools".

 

A long time is updated if you leave for a one specific server for updates.

 

Please elaborate more on this as it's not clear what you mean.

[roler 0]

I'm already so tired of the constant lies and total absence of the user service. Whatever you do and say. You just have one do not believe or say that it should be. Although this is not the case.
Enough considered fools users. Some of them have been around for decades on the computer and what you are trying to them to hide something only angers.

 

PS: After ten years of With such a pace of confidentiality on the computer, you can forget. Horror.

[itman 1,659]

 

@itman: This was explained by MMX in another topic:

 

There are two reasons ekrn.exe might make connections to servers that are not operated by ESET if you have TLS filtering enabled. First when a browser tries to establish a TLS connection, ESET Security needs to decide if it will filter, block or leave the connection untouched. This decision is in part based on the certificate the server would present if the connection was to proceed, which is not available yet. To solve this problem, ekrn.exe opens a separate connection and requests the certificate, which allows it to make the right decision in the main connection. This certificate is then cached so that the extra connection is not needed later which minimizes performance impact. Doing this is necessary to implement certificate exclusions (e.g. F5 -> Web and email -> SSL/TLS -> Exclude communication with trusted domains, or storing a certificate with Access set to Allow or Block).

 

Second reason is related to the fact that ESET Security needs to verify the validity of the certificate presented by the server. Online communication is a regular part of such verification (see https://en.wikipedia...Status_Protocol). Doing this is necessary to make sure that no attacker hijacked the connection in transit since your browser won't see the original certificate.

 

Please note that in both cases ekrn.exe sends only what a browser would send if ESET Security was not installed. In a way ekrn.exe acts on behalf of the browser. You can verify this by capturing the communication using wireshark and analyzing it (the initial part of TLS connection that ekrn.exe does in case 1 is not encrypted, and OCSP is not encrypted at all since it relies on digital signatures).

 

Thanks. That explains the double TCP connections; one to Eset servers for cert. verification and the other for the regular HTTPS connection until cert. verification completes.

[itman 1,659]

The only issue I have had with the Eset firewall is upon resume from stand-by. This also might be due to known DHCPv6 issues with Win 10 which I also believe exist for DHCPv4.

 

The problem is a strange inbound connection from svchost.exe - DHCP service with a remote address of the PC assigned IP address to the local DHCPv4 server address on the router for port 53. The router DNS server address is also that same IP address i.e. the router's IP address. If you think about this activity, it appears to be a borked DHCP request although I have seen tech references that DHCP can use port 53 to return a DNS server address.

 

So far, this activity has not occurred on ver. 10 so I hope it has been resolved.