itman

Is this still an issue? The large CRL cert. causing Eset memory spiking expired on Mar. 1. Was it renewed?

I scanned your domain, hxxps://librilettiscritti.it/, at Quttera. It contains 10 malicious files. The scan report: https://quttera.com/detailed_report/librilettiscritti.it , contains all the detail you need to find the malicious code references.
If you don't have the technical skills to remove this malware, you will have to hire someone; e.g. Quttera, to remove the malware for you.
In your case however, it appears this would be the webmaster responsibility since the malicious code is being injected from a remote source. That is, the web server is not properly secured and is probably infected.

As far as Eset's conducting monster-in the-middle (MITM) activities in regards to SSL/TLS protocol scanning, it might want to look into what Avast is doing: https://textslashplain.com/2019/08/11/spying-on-https/ .
Additional ref.: monster-in-the-browser attack (MITB)
-EDIT- For those interested, here's a formal scientific paper, 'The Security Impact of HTTPS Interception', published a few years back: https://zakird.com/papers/https_interception.pdf . This publication can be summed up in the following paragraph:
https://www.thesslstore.com/blog/ssl-inspection/

Actually, the web site is heavily infected; 30 malicious files found.
Refer to this Quttera web site scan report: https://quttera.com/detailed_report/rbs-egypt.com
As such, the entire web site should be blacklisted by Eset.

Post a screen shot of the popups you are receiving.

One last comment here and it's an important one.
Skirting the SSL/TLS protocol scanning use "debate," Eset needs to immediately stop certificate validation processing in regards to Firefox. It is the only browser past or present that performed certificate validation processing properly.
As it currently stands, the only way to remove Eset's certificate validation processing in regards to Firefox is to disable SSL/TLS protocol scanning.

Now if you want to add a Kaspersky feature to Eset, top on my list is System Watcher that can rollback malware system modifications including ransomware changes.

Cisco back in 2016 developed a Windows driver back in 2016 to prevent MBR write access: https://talosintelligence.com/mbrfilter . They promptly made the code open source and it can also be downloaded from Github here: https://github.com/Cisco-Talos/MBRFilter .
I brought this up in the forum shortly thereafter as to inclusion into Eset. It's now 2021 and still no MBR modification protection from Eset.

Nothing more exists that I could other than what was stated in this thread.

In regards to SSL/TLS protocol scanning being justified as to exploitation of browser vulnerabilities, a few additional comments.
What is relevant here is known exploitation of browser vulnerabilities and there is an organization that tracks those: https://www.cisa.gov/known-exploited-vulnerabilities-catalog . In the case of Firefox, three are listed. In the case of Chrome, a whopping 22 are listed.
-EDIT- All the above have been patched by their respective vendor.
In regards to browser vulnerabilities overall, 33 Intermediate level ones were recorded for Chrome in the last week: https://www.cisa.gov/uscert/ncas/bulletins/sb22-052
So if you're a Chrome user, it appears keeping SSL/TLS protocol scanning enabled for it makes sense. You also have no choice here due to the previously noted OCSP stapling issue in Chrome.
Also folks, this issue among many others is why I refuse to use Chrome.

I have used HIPS Smart mode setting ever since I have been using Eset; i.e. 8 years.
I am never received a HIPS alert from an internal based HIPS rule in this mode. As far as I am concerned, it is a "vapor-setting." Also, search past forum postings where others have posted the same.

Not a good enough reason for me. Why? Because it implies Eset has the ability to detect 0-day exploits which is certainly not the case.
-EDIT- This also brings up an issue that I am increasingly having an issue with using Eset.  The issue is Eset is a "one solution fits all product." Eset consumer products are for the most part, a "port" of their Endpoint version.
In commercial IT environments, it is a common but, abet insecure practice, to delay software patching. This practice would hold true for browsers. As such, protection for known browser exploits would make sense.
Most home users on the other hand would be running their browser at default settings. One of these default settings is to have the browser auto update. This in turn ensures the latest vulnerabilities are patched resulting in known exploits being a moot point.

OK. I got it.
Eset is actually inspecting the script code after it has been decrypted by the browser. In other words, the "proper" way AV's should be examining web site code.
As such, what other reasons are there for employing SSL/TLS protocol scanning? The vast majority of web site malicious code is script based.

Please explain how Eset's JavaScript scanner can scan encrypted code.

Then, AMSI scanner is indeed employed.

Yes, I realize that. But since the code is still encrypted, this .dll can't scan it.
Are you stating that Eset in violation of the user's explicit instruction not to scan browser encrypted code is still doing so?

I am going to make another posting and it's in regards to Eset's SSL/TLS protocol scanning of browser network traffic.
I previously posted that I felt my existing browser only based protections were adequate to protect me against web site based malware:
I set about to test my this assumption. For this test and again with Eset SSL/TLS protocol scanning disabled for Firefox, I tested at web site that Eset had previously detected a malicious script. Although the original Eset detection was two months ago, my hunch, which proved correct, was this web site was still infected implying it was most likely done intentionally by the web site developer.
Below is the Eset original detection with SSL/TLS protocol scanning enabled:
Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
12/28/2021 2:46:00 PM;HTTP filter;file;https://baysuit.org/wp-content/themes/obour/js/swiper.min.js?ver=5.8.2;JS/Agent.PIV trojan;connection terminated;XXXX\XXX;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (E36F9A16D60EFAAF370C07A99559B78476BD8AAA).;81FC52AD86F1CFF308D71444EB305697B81D49B2;
The detail to note at this point is Eset detected using its HTTP filter indicating Eset was examining SSL/TLS protocol scanned decrypted code.
Here is the result of accessing the same web site yesterday with SSL/TLS protocol scanning disabled:
Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
2/20/2022 4:05:08 PM;JavaScript scanner;file;https://baysuit.org/wp-content/themes/obour/js/comments.js?ver=495eca89ae6a299dbcae062d611592bc;JS/Agent.PIV trojan;blocked;XXX\XXX;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (DDA2DF4674CFAC53C721366914D7CD6F8A4A84DA).;01F58FB0AAFF6CBBB313B0017A69CE650F82391C;
Of note with this recent detection is although the hashes for the two detection's differ, Eset's malware identification is the same. This would be indicative of the creator of the malicious script creating a new variant in hopes of evading AV signature detection. Also assumed is the script was moved to a new WordPress plug-in to further obfuscate AV detection.
Most important with the recent Eset detection is it was made via Advanced Script Scanner. Err ....... how is that possible with SSL/TLS protocol scanning disabled?
Finally, browser based protections alone are not enough to detect browser based malicious scripts. Your only alternative is to use a browser extension such as NoScript which blocks all script execution. Then whitelist web sites you frequent that are known to be safe. Obviously, few will tolerate doing so.
In any case, Eset SSL/TLS protocol scanning on my device will remain permanently disabled for Firefox.

https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning
Again, just one more example where the critics of AV's performing SSL/TLS protocol scanning are most justified in their criticisms.

https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning
Again, just one more example where the critics of AV's performing SSL/TLS protocol scanning are most justified in their criticisms.

One last comment and I am done with this thread. Note that what I will post here is a statement and not a recommendation. Only you can decide what is best for you.
I have disabled SSL/TLS protocol scanning for Firefox. It will remain disabled at the minimum till Mar. 1; the ssca-sha2-g6.crl expires Feb. 28. I will reevaluate then but at this point, it will probably be a permanent status.
The most noticeable impact of disabling SSL/TLS protocol scanning is it busts Eset phishing protection. No problem there, Google Safe Browsing detects phishing web sites equal to and in most cases, better than Eset.
I disabled Firefox's HTTPS Everywhere because this current issue is N/A for HTTP web sites and Eset can scan those.
As far as Eset scanning for malware on HTTPS sites, Google Safe Browsing also does this along with PUA detection. I also use uBLock Origin with multiple malware and adblock filter lists selected. 
I also am enjoying how much better performance-wise Firefox runs with SSL/TLS protocol scanning out of the picture. Plus, Eset Service memory now runs at average around 30 MB.
For you Chrome and Edge users, you're SOL. Neither, past or present, have ever supported OCSP stapling as Firefox always has.

Yesterday, I downloaded the CRL's discussed in this thread. I am going to try one last time to illustrate what the issue is in regards to Eset improperly processing certificates with altered chain paths in the simplest way I can. I do have my doubts however, this issue will "register" with the Eset developer responsible for certificate validation processing.
Below is a screen shot of the download for CRL's mentioned in this thread.

The main thing to note at this point is that ssca-sha2-g6.crl is huge and contains all the recently revoked Let's Encrypt certs..
Below is the cert. associated with ssca-sha2-g6.crl:

The next thing to note is the CRL cert. was issued by DigiCert SHA2 Secure Server Intermediate CA. At this point, we can conclude DigiCert SHA2 Secure Server Intermediate CA cert. being used is the one containing the altered cert. chain path discussed previously.
I will now again refer to this domain, https://imgur.com/ , discussed previously and briefly review that discussion:
1. This domain is excluded from Eset SSL/TLS protocol scanning via whitelisting. As such, Eset should not be performing any certificate validation processing in regards to this domain/sub-domains.
2. This domain's web site cert. uses the ssca-sha2-g6.crl; see below,which in turn results in the DigiCert SHA2 Secure Server Intermediate CA cert. containing the altered certificate chain being used.

When https://imgur.com/ is accessed via the browser, one would expect a significant increase in browser memory to accommodate the 66 MB  ssca-sha2-g6.crl  being scanned. There should be no increase in Eset Service memory since  https://imgur.com/ is excluded from Eset SSL/TLS protocol scanning. As such, Eset should not be performing any certificate validation processing. As previously posted, this is not happening and Eset is loading 66 MB  ssca-sha2-g6.crl in Eset Service memory.
Far worse as previous posted is when https://imgur.com/ is not excluded from Eset SSL/TLS protocol scanning, no Eset Service memory spiking occurs indicating Eset has not loaded the the 66 MB  ssca-sha2-g6.crl into Eset Service memory and no certificate validation processing is being performed as required.
The above clearly illustrates that Eset has a serious problem with processing web sites using altered certificate chains and this problem has existed for some time. The problem has only now become evident due to a visible increase in Eset Service memory.
Then there is the additional issue of when Eset does load the the 66 MB  ssca-sha2-g6.crl into memory, why does Eset Service memory use increase by 200 MB?
I also believe it is time to report this situation to the various research orgs. that "take delight" in lambasting AV solutions for performing SSL/TLS protocol scanning with their emphasis on how certificate validation processing is not properly performed.

Yes, I am "one step away" from following them.

I also know about this CRL and consider it an "anomoly" to what I have posted in regards to Eset not having issues in regards cert. chain modification issues for SSL/TLS protocol scanned web sites. That is Eset "chokes" and loads the entire Microsoft aggregate CRL into Eset Service memory on this web site.
It so happens that the old Gibson Research web site revoked cert. test uses a cert. with this CRL:

First note that this GRC revoked cert. test is quite old.
I believe the problem is that the CRL format is no longer valid; i.e. the referencing CA root cert. CRL no longer exists.
In any case, the fact this was mentioned shows you are still "totally oblivious" to what I have been posting the issue is. I see at this point, no major issues with Eset cert. revocation in regards to SSL/TLS filtered web sites. The issue is Eset is also performing cert. revocation checking on non-SSL/TLS filtered web sites and it should not be doing so.
I also see I have again wasted my time "criticizing" anything Eset does not want to acknowledge is a problem.
BTW - keep your "self-patronizing" comments to yourself.

I don't have Chrome installed and refuse to use it.
I tested with Edge. Assumed is Chrome, like Edge, has blocked any access to the URL. Reason - HTTPS Everywhere most likely. See the below screen shot. Therefore, Eset processing is never invoked.

I am going to try one last time to show the problem with the simplest example I have found. After this posting, I am done with this issue.
With Eset Service consuming normal memory amount, open Firefox and attempt to access either of the following URLs:
http://crl3.digicert.com/DigiCertGlobalRootCA.crl
http://crl4.digicert.com/DigiCertGlobalRootCA.crl
Eset Service memory spikes indicating that Eset has loaded the aggregate Microsoft CRL. Note at this point, you don't have to download anything. Just the access will cause Eset Service memory to spike.
First, these are HTTP web sites and as such, Eset SSL/TLS protocol filtering is N/A. Most relevant however is HTTP sites are not certificate protected.  Yet it appears Eset is performing its cert. revocation checking processing as evidenced by Eset Service memory spiking.