Posolsvetla

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 Hello extension. It seems that the server requires the presence of x25519 group despite it's not mandatory, according to the https://tools.ietf.org/html/rfc8446#section-9.1 As can be seen on https://www.ssllabs.com/ssltest/analyze.html?d=www.rahvastikuregister.ee, Java 11.0.3 or Java 12.0.1 as a client has the same issue.

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.

We were able to reproduce the issue and obtained the log files which confirm the bogus data are added by our product.

Not sure if this is important and would make any difference, but there is missing charset=utf-8 in the content-type header sent by the server.

I checked the provided logs for GET /6.board-5991e97616a5fcf95475.js (as indicated by the screenshot) and there is no garbage at the end in the data passed to the browser. The data have length of 18682 bytes. Wireshark capture is sometimes needed in order to diagnose some kinds of issues. This is not the case.