Posolsvetla

Hi, no, unfortunately there is nothing new.

We will take care of the issue, but please note it might take some time as there might be more urgent work to be done. I will sent you a PM when it's released for business users. Please do not expect it to be soon, e.g. the usual release workflow (in cases like this) lasts several weeks.

The source code of only Chrome and Firefox was checked. The majority, if not all, of the browsers are expected to behave similarly. Probably not. But as it's been like this for several years already, you are the 1st (AFAIK) to actually care enough to report the issue.

This is intended behavior of both Chrome and Firefox. We serve the blocking page with HTTP/1.0 403 Blocked by ESET Security, as the immediate response to CONNECT blocked.domain.com:443 HTTP/1.1 Such response is blocked by browsers, and therefore not shown, in the case of https for security reasons, see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=137891 In order to make the browsers show the page we would need to proceed with the tunnel establishment and serve the blocking page only in there. Currently there is no ETA when this change will be done. It would be impleme

If you mean customized messages, than no, it's not possible to setup multiple, each one for different scenario.

In most cases only domain is sent, but the whole URL can be sent as well. The URL part after ? or # is not sent. Currently the URL can be quite easily read from the request, however these days we are in the process of releasing a new functionality for the encryption of these requests. The process should be finished in November if no blocking issues emerge. The URLs are not kept at our servers at all.

We are already investigating an issue with the same symptoms, so it might be the same issue in fact. Does the certificate used on the server have CRL Distribution Point X509 extension? If so, is the URL in there accessible on the affected local machine? The certificate is verified using the functionality OS provides. As a part of that process, the URL mentioned above is accessed.

I wasn't able to reproduce it with the version 1388.4 The version 1398 was released only for a few days and than replaced with 1388.4 The issue is only present in the version 1398 and will be fixed in 1399

I was able to reproduce this issue with Internet protection module 1398. Do you have the same version?

Unfortunately we are not able to provide any update on this issue yet.

According to our testing of www.rahvastikuregister.ee, the issue is on the server side. We recommend you to contact the server administrator. In the meantime, we recommend to add the server certificate of www.rahvastikuregister.ee into the List of known certificates (https://help.eset.com/eav/13/en-US/?idh_config_epfw_ssl.html) and set Scan action to Ignore. The technical details discovered during the testing which might be useful: The issue is present when there is TLS version 1.3 advertised in the Client Hello, but there is not advertised x25519 group in the Supported Groups Client

The issue is fixed in the Internet protection module version 1396; currently it is available on pre-release update servers.

This is very likely the issue we are already aware of. It manifests itself only on a fresh install of our product. It will be addressed by the Internet protection module update.

CVE-2020-0601 is related to ECC, not SHA1. Only Win10 were affected. We have implemented the detection of the attack shortly after is was published, so our users are protected (to be precise, this applies only to the TLS connections scanned by Web access protection, not the complete protection of the whole OS) even if they don't have the Win patch installed.

We already tried to solve this issue. Unfortunately, there is no general solution which would work out-of-the-box. Currently it's put on-hold and there is no progress being made on this.