Memory Usage

[itman 1,659]

1 hour ago, itman said:

Note this will have no effect on web sites that Eset performs SSL/TLS protocol scanning on since it chains the web site cert. directly to its own root cert..

Here's a simpler "fix" Eset can implement.

Here's a domain, https://imgur.com/ , that Eset CRL checking goes spastic on since it is using a cert. that chains to the DigiCert Intermediate cert. noted in my above posted entry. It also happens this domain is excluded from Eset SSL/TLS protocol scanning via internal whitelist.

What happens if this domain is not excluded from Eset SSL/TLS protocol scanning? Eset does not go spastic when performing CRL validation processing and no Eset Service memory spiking occurs. Why? Because Eset has directly chained the web site cert. to its root cert. eliminating the troublesome DigiCert Intermediate CA cert.. and is using its own cert. for CRL checking.

Therefore all Eset has to do is exclude from Eset SSL/TLS protocol scanning via internal whitelisting any web site using the troublesome DigiCert Intermediate CA certs..

Edited February 16, 2022 by itman

[SYS 1]

On 7. 2. 2022 at 6:36, Minimalist said:

Try going to this site and see if RAM consumption will increase on your system: https://siol.net/

It always does on my system.

I have the same RAM problem as I describe here in Chrome 98.0.4758.82 / W10
After opening the site https://siol.net/, which
here stated "Minimalist" my RAM increased from 150 to 350 MB and did not decrease.
RAM does not decrease even after closing the browser.
RAM will increase
- even after each downloaded NOD update - and no longer drops
- even after opening a new browser tab - and no longer drops
- even after checking or scanning the PC - and it no longer drops
... grows to 650 MB !!!

When e.g. I enable memory tracking in the "Protocols" settings,
RAM drops to 120 MB, but starts growing again ....

I don't run other software like MBAM.

[Marcos 5,074]

13 hours ago, SYS said:

I have the same RAM problem as I describe here in Chrome 98.0.4758.82 / W10

Please carry on as follows:
- enable memory tracing in the advanced setup -> tools -> diagnostics and click OK to save settings
- enable advanced operating system logging in the advanced setup -> tools -> diagnostics
- launch Chrome
- reproduce higher memory consumption by ekrn (> 600 MB)
- stop logging
- collect logs with ESET Log Collector and provide the generated archive for perusal.

[itman 1,659]

58 minutes ago, SYS said:

After opening the site https://siol.net/, which
here stated "Minimalist" my RAM increased from 150 to 350 MB and did not decrease.

Same problem that manifests with the DigiCert Intermediate cert. issue posted previously. GoDaddy is sending an "intermediate" root CA and chaining it to the original root CA to get around the SHA1 CRL signing issue:

This also unfortunately illustrates the issue is not exclusive the DigiCert Intermediate CA cert. I highlighted.

This problem will keep reoccurring until Eset finds a way to handle this on-the-fly downloading of altered cert. chain path processing that browsers are invoking to get around the SHA1 CRT signing issue.

Edited February 16, 2022 by itman

[itman 1,659]

I also believe it is time Eset disable its certificate revocation checking processing for all non-SSL/TLS protocol scanned web sites until they can accommodate this downloading of altered cert. chain path processing that browsers are invoking.

[New_Style_xd 69]

My concern and when is it said that there will be a correction in the future, rather than the future? Next year 2023, in ESET version 16?

[itman 1,659]

"It's time to cut to the chase" on this issue since my patience is "wearing thin."

It is fairly obvious that Eset, either directly or indirectly, is performing certificate chain validation checking as part of its background processing. It has also been doing this incorrectly for some time.

The correct way to perform cert. chain validation is when a web site is accessed the thumbprint of the terminating; i.e. top of the chain root cert. is extracted. Then an identical web site access is made via a secured server and the same process is repeated. If the two accessed thumbprints match, the chain is valid and no man-in-the-middle activity has occurred. If any other cert. chain validations are performed, it will lead to incorrect results. Why?

It is a common but infrequent practice of CA's that when there is a non-security related issue with a root certificate to "patch" the chain by having the browsers insert a new root cert. in the chain and then chain this new root cert. to the original root cert.. This will avoid having the CA issue thousands of new certificates and the costs associated with that.

From what I have observed, Eset has not been handling the cert. chain "patching" correctly for some time. So this needs to be fixed immediately, or Eset bypass cert. chain validation processing. The "mystery" at present is why Eset is now reverting to loading the entire aggregate Windows cert. revocation list into memory when this cert. patching occurs. Again, the solution is for Eset to either fix their cert. chain validation processing or bypass it entirely.

Edited February 17, 2022 by itman

[MMx 28]

8 hours ago, itman said:

It is fairly obvious that Eset, either directly or indirectly, is performing certificate chain validation checking as part of its background processing. It has also been doing this incorrectly for some time.

Unfortunately it is far from obvious for me that there's any problem with certificate validation. Please help me understand how you arrived at this conclusion. Can you post a step-by-step description of a scenarion that lead you to this conclusion and also describe what was the expected result and what was the actual result?

8 hours ago, itman said:

The "mystery" at present is why Eset is now reverting to loading the entire aggregate Windows cert. revocation list into memory when this cert. patching occurs.

Please note that the behavior related to loading CRLs into memory you're describing is implemented inside the Windows API function CertGetCertificateChain: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain I can try to see if it is possible to tweak it based on the information I've requested above, but please note that this is the default behavior of the OS that is also used for example by the Chrome browser: https://source.chromium.org/chromium/chromium/src/+/main:net/cert/cert_verify_proc_win.cc;l=1207?q=CertGetCertificateChain&ss=chromium

[itman 1,659]

8 hours ago, MMx said:

Unfortunately it is far from obvious for me that there's any problem with certificate validation. Please help me understand how you arrived at this conclusion. Can you post a step-by-step description of a scenarion that lead you to this conclusion and also describe what was the expected result and what was the actual result?

First, I posted in this thread a detailed example of certificate chain "patching" in this thread: https://forum.eset.com/topic/31282-memory-usage/?do=findComment&comment=146973 .

As far as this reference is concerned: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain

Quote

You can also set the following revocation flags, but only one flag from this group may be set at a time.

Table 2

Value	Meaning
CERT_CHAIN_REVOCATION_CHECK_END_CERT 0x10000000	Revocation checking is done on the end certificate and only the end certificate.
CERT_CHAIN_REVOCATION_CHECK_CHAIN 0x20000000	Revocation checking is done on all of the certificates in every chain.
CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT 0x40000000	Revocation checking is done on all certificates in all of the chains except the root certificate.

 

It appears that root certificates using SHA1withRSA are no longer valid for CRL purposes. You will have to ask Microsoft about this one. Again, refer to the above GoDaddy cert. chain I posted. It would appear that CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT option would get around the current chain "patching"  issue but I have doubts. That is what happens if the cert. chain has two root certs. present which is very much the case presently? Again, refer to the above DigiCert chain I posted. The inserted "patched" root certificate is an altered DigiCert Global Root certificate  that in reality is the existing cert. with SHA2withRSA capability that is chained to the chain terminating BaltimoreTrust root certificate. Bottom line - this altered DigiCert Global Root certificate would be the one used for CRL purposes. The problem is the Windows crypto API doesn't have an option for this.cert. chain "patching" My conclusion is when cert. chain "patching" is evident; i.e. two root certs., Eset needs to "bow out" of CRL checking and let the browser handle it. As far as past Eset issues when certificate chain "patching" occurred, search the forum for prior postings in regards to web site access issues when a "patched" certificate chain was in effect. BTW - Firefox is the only browser that handles certificate chain "patching" properly in that, it actually is using an Intermediate CA cert. from its Authorities store that contains the "patched" chain. -EDIT- The problem here is Microsoft doesn't approve of cert. chain "patching" and therefore won't support it. The CA's in turn say "up your nose with a rubber hose" to Microsoft. Their my certificates and as long as their standard's organization allow  cert. chain "patching," they are going to do it. The browser manufacturer's caught in the middle, go along with what the CA's want.

Edited February 17, 2022 by itman

[itman 1,659]

This article by Quttera: https://blog.quttera.com/post/what-happens-ssl-certificate-trust-chain-breaks/ . Of interest is: .

Quote

Modern browsers don't generally check the full chain. If they know that the first signing certificate is valid, they'll continue to trust it. This saves a lot of interaction with servers. Some users, though, will be affected and see browser warnings. This can be a confusing situation to diagnose. Quttera ThreatSign checks certificates thoroughly, so that you know which ones have become invalid before your customers complain.

First, in regards to Firefox's Authorities store, note that less than a handful of Intermediate CA certs.. exist. One of those is the DigiCert SHA2 Secure Server CA cert.. I have posted previously about. These Intermediate CA certs. in Firefox's Authorities store function as an "override" to the Intermediate cert. downloaded, if needed, by the browser from the web site server. Since browsers use the Intermediate cert. for chain validation purposes, Firefox uses the DigiCert SHA2 Secure Server CA cert. in its Authorities store and bypasses the Intermediate CA cert. download from the web site.

One possibility here is when the Win crypto API is invoked for cert. revocation status determination, it bypasses any browser modification/download  activities in regards Intermediate cert. usage and instead is using a Microsoft supplied web server Intermediate CA cert. download. This would also explain why the GoDaddy cert. example posted previously failed. In the GoDaddy case, the altered Intermediate CA cert. existed on the origin web server only; it is not present in the Firefox Authorities store.

Edited February 18, 2022 by itman

[itman 1,659]

I will also state this in regards to Eset's use of the Win crypto API.

Eset by virtue of it's SSL/TLS protocol filtering feature is responsible for cert. validation processing normally performed by the browser. Namely, certificate revocation status processing. Assumed is the Win crypto API cert. revocation processing is invoked and is one way to so. My prior testing as previously posted shows no issue in regards to SSL/TLS protocol filtered web sites:

Quote

Here's a domain, https://imgur.com/ , that Eset CRL checking goes spastic on since it is using a cert. that chains to the DigiCert Intermediate cert. noted in my above posted entry. It also happens this domain is excluded from Eset SSL/TLS protocol scanning via internal whitelist.

What happens if this domain is not excluded from Eset SSL/TLS protocol scanning? Eset does not go spastic when performing CRL validation processing and no Eset Service memory spiking occurs.

As I see it, there is no reason Eset should be performing the above processing for non-SSL/TLS protocol filtered web sites. Is it possibly that some one at Eset got "overly creative" in invoking the Win crypto API cert. revocation processing in this regard?

-EDIT- The above does raise this question. When Eset invokes the Win crypto API cert. revocation processing is the API properly performing its cert. revocation checking?

Edited February 18, 2022 by itman

[MMx 28]

16 hours ago, itman said:

First, I posted in this thread a detailed example of certificate chain "patching" in this thread: https://forum.eset.com/topic/31282-memory-usage/?do=findComment&comment=146973 .

I tried to understand your reasoning to the best of my ability and I believe you've made one key mistake.

Quote

I had for a while noticed that Eset memory spiking occurred on web sites using a cert. chained to this Intermediate CA cert., DigiCert SHA2 Secure Server CA.

You're mistaking correlation for causality. Just because two things happen one after the other doesn't mean that the first is causing the second. For example they might be both caused by another factor you've not considered. For a more in-depth explanation please refer for example to https://amplitude.com/blog/causation-correlation

In order to put forth a convincing case you'll need evidence to support your claims. It might look like this:

1. The etl log created as ekrn was allocating the memory shows that about 64MB has been allocated as

• protoscan module was trying to verify a certificate using Windows API, which in turn
• called a function to verify revocation status which in turn
• called a function to download the corresponding Certificate Revocation List which in turn
• allocated the memory as the CRL was being loaded

(another 64MB can be traced to a similar call stack)

2. We know of a CRL that is this big: http://crl3.digicert.com/ssca-sha2-g6.crl Coincidentally this CRL has been issued by "DigiCert SHA2 Secure Server CA", so this might be the source of the correlation you're pointing out.

3. During an investigation of a different ticket we've looked into the allocation and found that it contains an exact copy of the downloaded CRL, so we know that this function is capable of loading the entire file into memory.

Unless you can provide more compelling evidence supporting your cause we'll have to treat claims such as these as your personal beliefs:

Quote

the problem is Eset "chokes" on the processing of intermediate root certs. thereby borking the entire chain validation processing.

I've also noticed several less relevant mistakes in your claims. I can explain those if you're interested, but I'd like to keep the discussion to the point for now so as to not moot the point. Ultimately they are of little consequence because of the wrong assumption you've made at the beginning.

[Posolsvetla 15]

I would like to address several other points, not directly related to the original topic.

On 2/9/2022 at 5:11 PM, itman said:

In any case, Eset is monitoring this Firefox certificate update activity;

As far as I know, we don't monitor this in any special way, just as any other download.

On 2/9/2022 at 10:36 PM, itman said:

The problem is when Win cert. data is loaded in Eset Service memory out of sequence, the normal handshake process between Firefox and Eset for removal doesn't occur.

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 )

On 2/10/2022 at 1:00 AM, itman said:

Eset will query via OSCP the issuing CA server. It then proceeds to download all these revoked certs.

If OCSP takes place when checking of a particular certificate, there is no CRL downloaded for it.

On 2/10/2022 at 8:07 PM, itman said:

Eset did not detect the two expired cert. tests. However, at least Firefox detected the expired certs..

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.

On 2/10/2022 at 8:07 PM, itman said:

The above leads to the conclusion Eset SSL/TLS protocol scanning has an issue with expired cert. detection.

See the comment above.

On 2/16/2022 at 3:59 PM, itman said:

add Intermediate cert. revocation checking bypass exclusion capability.

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.

On 2/16/2022 at 3:59 PM, itman said:

Eset needs to allow for disabling of its certificate revocation checking processing. Note this will have no effect on web sites that Eset performs SSL/TLS protocol scanning on since it chains the web site cert. directly to its own root cert..

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.

On 2/16/2022 at 5:15 PM, itman said:

Because Eset has directly chained the web site cert. to its root cert. eliminating the troublesome DigiCert Intermediate CA cert.. and is using its own cert. for CRL checking.

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.

On 2/16/2022 at 8:29 PM, itman said:

on-the-fly downloading of altered cert. chain path processing that browsers are invoking to get around the SHA1 CRT signing issue.

I'm not familiar with "SHA1 CRT signing issue". However, see the answer below.

On 2/16/2022 at 8:43 PM, itman said:

disable its certificate revocation checking processing for all non-SSL/TLS protocol scanned web sites until they can accommodate this downloading of altered cert. chain path processing that browsers are invoking.

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.

On 2/16/2022 at 11:19 PM, New_Style_xd said:

My concern and when is it said that there will be a correction in the future, rather than the future? Next year 2023, in ESET version 16?

The year 2023 is quite optimistic IMHO, though not impossible...

On 2/17/2022 at 1:21 AM, itman said:

The correct way to perform cert. chain validation is when a web site is accessed the thumbprint of the terminating; i.e. top of the chain root cert. is extracted. Then an identical web site access is made via a secured server and the same process is repeated. If the two accessed thumbprints match, the chain is valid

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.

21 hours ago, itman said:

Eset needs to "bow out" of CRL checking and let the browser handle it.

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.

17 hours ago, itman said:

These Intermediate CA certs. in Firefox's Authorities store function as an "override" to the Intermediate cert. downloaded, if needed, by the browser from the web site server. Since browsers use the Intermediate cert. for chain validation purposes, Firefox uses the DigiCert SHA2 Secure Server CA cert. in its Authorities store and bypasses the Intermediate CA cert. download from the web site.

As I have mentioned, we fixed this, so now we look for the alternate intermediate certificate.

[itman 1,659]

7 hours ago, MMx said:

2. We know of a CRL that is this big: http://crl3.digicert.com/ssca-sha2-g6.crl Coincidentally this CRL has been issued by "DigiCert SHA2 Secure Server CA", so this might be the source of the correlation you're pointing out.

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.

Edited February 18, 2022 by itman

[New_Style_xd 69]

45 minutes ago, itman said:

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. no referencing CA root cert. CRL, or simply the 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 "patronizing" comments to yourself.

This is the main reason why other users stopped using ESET products, and went to Kaspersky, because the ESET team doesn't understand the problem that was posing. Are they reading what you've been posting for several days?

[itman 1,659]

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.

Edited February 18, 2022 by itman

[itman 1,659]

17 minutes ago, New_Style_xd said:

This is the main reason why other users stopped using ESET products, and went to Kaspersky, because the ESET team doesn't understand the problem that was posing.

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

[New_Style_xd 69]

18 minutes ago, itman said:

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:

hxxp://crl3.digicert.com/DigiCertGlobalRootCA.crl
hxxp://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. Yet it appears Eset is performing its cert. revocation checking processing as evidenced by Eset Service memory spiking.

I stopped here to do a test, I restarted my computer this with <50.
The test I'm doing is with google chrome now because I know firefox goes to >200.
Open Google Chrome I went to the link you posted. when I click to open the link you informed chrome does not open, the screen is blinking. I noticed that chrome does not let you open the link, test it on your pc with google chrome

[itman 1,659]

33 minutes ago, New_Style_xd said:

I stopped here to do a test, I restarted my computer this with <50.
The test I'm doing is with google chrome now because I know firefox goes to >200.
Open Google Chrome I went to the link you posted. when I click to open the link you informed chrome does not open, the screen is blinking. I noticed that chrome does not let you open the link, test it on your pc with google chrome

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.

Edited February 18, 2022 by itman

[itman 1,659]

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.

Edited February 19, 2022 by itman

[itman 1,659]

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.

Edited February 19, 2022 by itman

[Marcos 5,074]

A couple of off-topic comments hidden. Please keep the discussion to the point.

[MMx 28]

On 2/18/2022 at 4:37 PM, itman said:

The issue is Eset is also performing cert. revocation checking on non-SSL/TLS filtered web sites and it should not be doing so.

Unfortunately you're wrong here. If someone performs a Man-in-the-Middle attack on your connection to imgur.com it's very likely they will try transferring malware or other content of security interest to the user. In that case we very much want to scan that connection. And the only way to detect that attack is to verify the certificate. We don't want to whitelist anything that's called imgur.com, we only want to whitelist the actual imgur server.

[SYS 1]

I tried to do the same as I wrote here in my post, but with a different AV.
I uninstalled NOD
I installed AV K ******** and opened this page in Chrome https: //siol.net/
Programs like MBAM and the like have not been run.
 
After opening it with NOD, my RAM jumped from the initial 130 MB to 350 MB, but it did not decrease. After opening more www, it only grew to 600 MB and remained without a decline even after Chrome was completely shut down.
After opening it with K ********, my RAM jumped from the initial 60 MB to 260 MB and after a while it returned to the original 60 MB and I have no problems with other www.
Even after a long monitoring, the RAM stays at 50-70 MB

I can't describe it professionally here, but I think the problem will really be in NOD.

[New_Style_xd 69]

19 minutes ago, SYS said:

I tried to do the same as I wrote here in my post, but with a different AV.
I uninstalled NOD
I installed AV K ******** and opened this page in Chrome https: //siol.net/
Programs like MBAM and the like have not been run.
 
After opening it with NOD, my RAM jumped from the initial 130 MB to 350 MB, but it did not decrease. After opening more www, it only grew to 600 MB and remained without a decline even after Chrome was completely shut down.
After opening it with K ********, my RAM jumped from the initial 60 MB to 260 MB and after a while it returned to the original 60 MB and I have no problems with other www.
Even after a long monitoring, the RAM stays at 50-70 MB

I can't describe it professionally here, but I think the problem will really be in NOD.

Exactly, and that's what everyone here has been saying, the problem is in the NOD, with other security programs it's working normally, but when and with NOD the RAM increases a lot.