Posolsvetla

We cannot stop validating certificates.
We don't do it because some browser might do certificate validation incorrectly. We do it because if TLS scanning is active for a particular web site, a browser cannot validate the original certificate of that site. (Note: As already discussed previously, we validate certificates also in several cases when TLS scanning is not active for a web page in question.)
What would happen if we stopped validating certificates can be simulated like this:
As per https://help.eset.com/eis/15/en-US/?idh_config_epfw_ssl_known.html add the certificate for https://untrusted-root.badssl.com/ and set the Access action to Allow. This way, the server's certificate will be considered valid by our product with the same effect as if we didn't validate it. (Note: As already mentioned, the revoked certificates won't be considered valid even if configured so.) Then try to open that web site. It will succeed.
I managed to find a few links which might be helpful for anybody reading this forum:
https://medium.com/@ethicalevil/how-http-proxies-read-tls-traffic-from-browsers-f15364e91226
https://security.stackexchange.com/questions/133254/how-does-ssl-proxy-server-in-company-work
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/#transparent-https
https://en.wikipedia.org/wiki/TLS_termination_proxy
According to Wikipedia, we use "TLS termination proxy" of "TLS Bridging" type in order to be able to do TLS scanning.

We cannot stop validating certificates.
We don't do it because some browser might do certificate validation incorrectly. We do it because if TLS scanning is active for a particular web site, a browser cannot validate the original certificate of that site. (Note: As already discussed previously, we validate certificates also in several cases when TLS scanning is not active for a web page in question.)
What would happen if we stopped validating certificates can be simulated like this:
As per https://help.eset.com/eis/15/en-US/?idh_config_epfw_ssl_known.html add the certificate for https://untrusted-root.badssl.com/ and set the Access action to Allow. This way, the server's certificate will be considered valid by our product with the same effect as if we didn't validate it. (Note: As already mentioned, the revoked certificates won't be considered valid even if configured so.) Then try to open that web site. It will succeed.
I managed to find a few links which might be helpful for anybody reading this forum:
https://medium.com/@ethicalevil/how-http-proxies-read-tls-traffic-from-browsers-f15364e91226
https://security.stackexchange.com/questions/133254/how-does-ssl-proxy-server-in-company-work
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/#transparent-https
https://en.wikipedia.org/wiki/TLS_termination_proxy
According to Wikipedia, we use "TLS termination proxy" of "TLS Bridging" type in order to be able to do TLS scanning.

We cannot stop validating certificates.
We don't do it because some browser might do certificate validation incorrectly. We do it because if TLS scanning is active for a particular web site, a browser cannot validate the original certificate of that site. (Note: As already discussed previously, we validate certificates also in several cases when TLS scanning is not active for a web page in question.)
What would happen if we stopped validating certificates can be simulated like this:
As per https://help.eset.com/eis/15/en-US/?idh_config_epfw_ssl_known.html add the certificate for https://untrusted-root.badssl.com/ and set the Access action to Allow. This way, the server's certificate will be considered valid by our product with the same effect as if we didn't validate it. (Note: As already mentioned, the revoked certificates won't be considered valid even if configured so.) Then try to open that web site. It will succeed.
I managed to find a few links which might be helpful for anybody reading this forum:
https://medium.com/@ethicalevil/how-http-proxies-read-tls-traffic-from-browsers-f15364e91226
https://security.stackexchange.com/questions/133254/how-does-ssl-proxy-server-in-company-work
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/#transparent-https
https://en.wikipedia.org/wiki/TLS_termination_proxy
According to Wikipedia, we use "TLS termination proxy" of "TLS Bridging" type in order to be able to do TLS scanning.

I would like to address several other points, not directly related to the original topic.
As far as I know, we don't monitor this in any special way, just as any other download.
There is no such thing implemented in our product which would be described as "the normal handshake process between Firefox and Eset for removal" of a certificate data loaded in the memory of our process. As has been mentioned already, it's not possible to force the memory flush; see: "The Windows operating system does not support manual or programmatic flushing of the CRL cache." (ref.: https://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx )
If OCSP takes place when checking of a particular certificate, there is no CRL downloaded for it.
We indeed detect expired certificates, however we don't act on it in any special way. Instead, we keep this expired date in the certificate the browser sees, so the browser can detect it itself.
See the comment above.
That would introduce a possibility for a security hole caused by a misconfiguration. It's not possible to configure such exclusions in browsers (AFAIK), so it's not possible to do so in our product.
Partially answered above.
The web site certificate is chained to our root certificate only because it's safe to do so, i.e. the certificate checks, including the revocation check, already passed.
Partially answered above.
Neither our product nor a browser do any revocation checking for the certificate chained to our root certificate. There is no point doing so, it's not possible that exact certificate is ever revoked.
I'm not familiar with "SHA1 CRT signing issue". However, see the answer below.
We had an issue, when a server was sending the wrong intermediate certificate, already fixed. Now we look also for the alternate one, but it must be already present in the certificate store on Windows. We don't download it ourselves. This is a subject for future improvements as already mentioned.
The year 2023 is quite optimistic IMHO, though not impossible...
This would be "root certificate pinning". We cannot do that. While it would work most of the time, it would immediately cause connection issues to the servers at the moment they changed CA for their server certificates.
As already mentioned, browsers do not do any revocation checking in the case TLS filtering is in effect. So we have to do it ourselves.
As I have mentioned, we fixed this, so now we look for the alternate intermediate certificate.

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.

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

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

This issue is fixed in the Internet protection module version 1382, which is currently in testing.
You will be able to remove https://esmc from the whitelist when it's released for your product version(s).

As I expected, this is a known issue. It's already fixed in the Internet protection module version 1382, which is currently in testing.
Unfortunately it will take some time until it's released for your version of ESET Endpoint Antivirus. The fixed module will download automatically then.
Until that time, you can keep using the value of 443 for Ports used by HTTPS protocol; alternatively, you can try the less invasive change of the default value with the value of "443, 0-79, 81-65535" or "443, 0-79, 81-6567, 6569-65535"

This seems like an issue we are already aware of.
Please proceed as described here: https://support.eset.com/kb7272/ , but please enable Protocol filtering advanced logging as well. Don't forget to disable logging before Part II.
Then please send me the created logs via PM.
Then, you can try if changing this setting makes any difference:
F5 -> Web and email -> Web access protection -> Web protocols -> Ports used by HTTPS protocol
Change the current value (I expect there is 443, 0-65535) to 443.
We don't need any logs from the state when the setting is changed, at least for now.
Thanks.

The notifications are not shown anymore, if our blocking web page is shown directly in a web browser.
Those notifications are redundant in such cases. It involves anti-phishing and PUA protection, to name a few cases.

This issue should be fixed by the Firewall module version 1391.1
Expected release on Pre-release update channel is the next week.
The issue is triggered by the update of the program.
If you clicked to keep the rule button in the dialog, the dialog should not show anymore.