Memory Usage

[Purpleroses 21]

I updated Firefox and had a windows 10 update.  Now Firefox seems to be alright.  But now I noticed when I use google chrome the usage goes up to 220 mb.  I just give up looking at the usage now.

[New_Style_xd 69]

1 hour ago, Purpleroses said:

I updated Firefox and had a windows 10 update.  Now Firefox seems to be alright.  But now I noticed when I use google chrome the usage goes up to 220 mb.  I just give up looking at the usage now.

I don't use chrome.
Now it's hard to know, I think the problem is not with the browsers, because of the problems reported I'm sure it's with ESET.

[Minimalist 16]

I updated Firefox to v.97 and behaviour on my system is the same as before (increased memory usage that doesn't decrease when I close Firefox).

[New_Style_xd 69]

1 hour ago, Minimalist said:

I updated Firefox to v.97 and behaviour on my system is the same as before (increased memory usage that doesn't decrease when I close Firefox).

Mine still remains in the same situation even closing firefox still continues to consume high ram memory.

I'm waiting for someone to inform when this problem will be fixed.

[Minimalist 16]

For me it's not a problem. Eset probably loads something when it needs and doesn't release it after it's not needed any more. Since it doesn't consume much memory and it stays at 240 MB for me it's really not a big deal.

To be frank I would even like them to use more memory if that would speed up system performance. I prefer for AV to use memory instead of a disk.

[Marcos 5,074]

Unfortunately it turned out to be a quirk of the Windows crypto API that is used for verifying certificates that ESET has no direct control over. It downloads large lists of revoked certificates and keeps them in memory even after all handles are released.

[Purpleroses 21]

So Marcos it is alright that Eset stays at 220mb  or so ?

[Marcos 5,074]

12 minutes ago, Purpleroses said:

So Marcos it is alright that Eset stays at 220mb  or so ?

It's not ok but we can't do anything about it since it's a Windows crypto API function that keeps data in memory. In the future we'll rework the routine so that the said crypto API function is not used.

The memory use depends on what SSL certificates we encounter and on the size of the cert. revocation list.

[itman 1,659]

2 hours ago, Marcos said:

It's not ok but we can't do anything about it since it's a Windows crypto API function that keeps data in memory. In the future we'll rework the routine so that the said crypto API function is not used.

The memory use depends on what SSL certificates we encounter and on the size of the cert. revocation list.

Things are finally "starting to add up."

Yes, Win crypto updates are getting to be large. Today's download was 60 MB.

However a few days ago, I noticed the following Firefox setting was disabled:

Why this was disabled is a mystery since I manually did not do so.

After previously enabling the Query OCSP setting and later the subsequent ver. 97 Firefox upgrade, Eset service memory usage will spike to over 200 MB when Firefox initially opened after first system startup of the day. Upon closing Firefox, Eset service memory usage returns to approx. 40 MB. Subsequent openings of Firefox do not increase Eset service memory usage.

Edited February 9, 2022 by itman

[itman 1,659]

As far as Win crypto updates are getting to be large, Let's Encrypt recently revoked a "whole bunch" of its certificates.

[New_Style_xd 69]

36 minutes ago, itman said:

Things are finally "starting to add up."

Yes, Win crypto updates are getting to be large. Today's download was 60 MB.

However a few days ago, I noticed the following Firefox setting was disabled:

Why this was disabled is a mystery since I manually did not do so.

After previously enabling the Query OCSP setting and later the subsequent ver. 97 Firefox upgrade, Eset service memory usage will spike to over 200 MB when initially opened after first system startup of the day. Upon closing Firefox, Eset service memory usage returns to approx. 40 MB. Subsequent openings of Firefox do not increase Eset service memory usage.

After having updated to version 97 mine was still marked normally.
I found it strange that yours was unchecked the box.

[itman 1,659]

1 hour ago, itman said:

After previously enabling the Query OCSP setting and later the subsequent ver. 97 Firefox upgrade, Eset service memory usage will spike to over 200 MB when Firefox initially opened after first system startup of the day. Upon closing Firefox, Eset service memory usage returns to approx. 40 MB. Subsequent openings of Firefox do not increase Eset service memory usage.

Detailed explanation as I see it.

Firefox will check daily for certificate updates. This occurs once a day when Firefox is initially opened. Firefox will then update its certificate store accordingly. Firefox also has internal settings to roll over to Windows certificate store. So this also might be a factor; especially if Firefox's Query OCSP setting is disabled or malfunctioning in some way.

In any case, Eset is monitoring this Firefox certificate update activity; hence the increased memory usage. If all goes as it should, Eset will release this increased memory usage when Firefox is closed. Firefox will not perform any additional certificate updating until the next system startup. Hence, no increased Eset memory usage on subsequent Firefox startups.

Edited February 9, 2022 by itman

[New_Style_xd 69]

1 hour ago, itman said:

Detailed explanation as I see it.

Firefox will check daily for certificate updates. This occurs once a day when Firefox is initially opened. Firefox will then update its certificate store accordingly. Firefox also has internal settings to roll over to Windows certificate store. So this also might be a factor; especially if Firefox's Query OCSP setting is disabled or malfunctioning in some way.

In any case, Eset is monitoring this Firefox certificate update activity; hence the increased memory usage. If all goes as it should, Eset will release this increased memory usage when Firefox is closed. Firefox will not perform any additional certificate updating until the next system startup. Hence, no increased Eset memory usage on subsequent Firefox startups.

Good possible analysis. makes a lot of sense. would anyone here on the forum have a very detailed explanation? Your explanation so far is the most complete I've ever checked. who can best answer in detail is the ESET development team. but you are congratulations

[itman 1,659]

I should also note that there are other things in Firefox that will cause Eset Service memory to spike and remain at an elevated level.

For example, the testing at badssl.com to verify that your AV's SSL/TLS protocol scanning has not borked the browser's native SSL/TLS certificate validation processing. When I performed the Dashboard test at badsll.com which performs a number of certificate validation tests, I passed all except the reversed-chain test. Of note and of interest, Firefox natively will detect this anomaly and block the connection.

After performing the Dashboard test, Eset Service memory to spiked to 200+ MB and remained at that level thereafter. This is unfortunately, current expected Eset behavior due to its loading of Win store certificate data to use for validation purposes in the test w/o Firefox expecting this to occur.

Edited February 9, 2022 by itman

[New_Style_xd 69]

19 minutes ago, itman said:

I should also note that there are other things in Firefox that will cause Eset Service memory to spike and remain at an elevated level.

For example, the testing at badssl.com to verify that your AV's SSL/TLS protocol scanning has not borked the browser's native SSL/TLS certificate validation processing. When I performed the Dashboard test at badsll.com which performs a number of certificate validation tests, I passed all except the reversed-chain test. Of note and of interest, Firefox natively will detect this anomaly and block the connection.

After performing the Dashboard test, Eset Service memory to spiked to 200+ MB and remained at that level thereafter. This is unfortunately, current expected Eset behavior due to its loading of Win store certificate data to use for validation purposes in the test w/o Firefox expecting this to occur.

Firefox when ESET is closed should consume <40MB again, and consume memory again when firefox was opened. and when firefox closes back to normal. that's what's bothering you. even with your perfect explanation, i would think that after closing firefox it should go back to consuming <40MB

[itman 1,659]

5 minutes ago, New_Style_xd said:

i would think that after closing firefox it should go back to consuming <40MB

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. Hence, the data remains in Eset Service memory.

Bottom line - this issue has always existed. It is only noticeable now due to the huge increase in revoked certs. from Let's Encrypt.

[Purpleroses 21]

I'm also finding high memory when using google chrome also.

[itman 1,659]

2 hours ago, Purpleroses said:

I'm also finding high memory when using google chrome also.

This Eset service memory consumption issue will manifest on all browsers where Eset performs SSL/TLS protocol scanning.

All it takes is to land on a web site using a Let's Encrypt certificate. Eset will query via OSCP the issuing CA server. It then proceeds to download all these revoked certs. and store them in its memory.

Assumed here is previous revoked certs. were relatively an insignificant number. Therefore, any increase in Eset memory was negligible. As such, Eset memory consumption increase was not an issue.

Leave it to Let's Encrypt to "muck up the works" again.

Edited February 10, 2022 by itman

[itman 1,659]

I did some additional research/testing.

As far as everything I have posted about Let's Encrypt recent en-mass cert. revocation being the source of Eset Service memory spiking, it is "phony baloney." In Mar., 2020, Let's Encrypt revoked over 3 million certs.. This at the time caused no issues with Eset Service memory spiking.

As far as @Marcosstatement that cert. revocation being the source of Eset Service memory spiking, I also state that is "phony baloney."

So what is the source of this Eset Service memory spiking?

I performed some certificate validation tests at this web site: https://www.ssl.com/sample-valid-revoked-and-expired-ssl-tls-certificates/ . Eset detected the two revoked certs. Eset did not detect the two expired cert. tests. However, at least Firefox detected the expired certs..

Now, back to the badssl.com cert. tests I referenced previously. Again, note that initial access to that site causes Eset Service memory to spike. Well, it so happens that the cert. for badssl.com is expired. As such, it can be inferred that all its sub domains used to test various cert. issues are using an expired cert..

The next test I performed is what happens in regards to Eset Service memory spiking if I access the badssl.com web site and perform the Dashboard tests with Eset SSL/TLS protocol scanning disabled? Guess what? No Eset Service memory spiking occurs.

The above leads to the conclusion Eset SSL/TLS protocol scanning has an issue with expired cert. detection. Eset implemented some "Band-Aid" solution which isn't working properly resulting in Eset Service memory spiking; it not being properly released; and "only God knows" what other borks may be occurring.

Edited February 10, 2022 by itman

[New_Style_xd 69]

1 hour ago, itman said:

I did some additional research/testing.

As far as everything I have posted about Let's Encrypt recent en-mass cert. revocation being the source of Eset Service memory spiking, it is "phony baloney." In Mar., 2020, Let's Encrypt revoked over 3 million certs.. This at the time caused no issues with Eset Service memory spiking.

As far as @Marcosstatement that cert. revocation being the source of Eset Service memory spiking, I also state that is "phony baloney."

So what is the source of this Eset Service memory spiking?

I performed some certificate validation tests at this web site: https://www.ssl.com/sample-valid-revoked-and-expired-ssl-tls-certificates/ . Eset detected the two revoked certs. Eset did not detect the two expired cert. tests. However, at least Firefox detected the expired certs..

Now, back to the badssl.com cert. tests I referenced previously. Again, note that initial access to that site causes Eset Service memory to spike. Well, it so happens that the cert. for badssl.com is expired. As such, it can be inferred that all its sub domains used to test various cert. issues are using an expired cert..

The next test I performed is what happens in regards to Eset Service memory spiking if I access the badssl.com web site and perform the Dashboard tests with Eset SSL/TLS protocol scanning disabled? Guess what? No Eset Service memory spiking occurs.

The above leads to the conclusion Eset SSL/TLS protocol scanning has an issue with expired cert. detection. Eset implemented some "Band-Aid" solution which isn't working properly resulting in Eset Service memory spiking; it not being properly released; and "only God knows" what other borks may be occurring.

What is making me more worried is ESET is not doing anything to identify and solve this problem, and no one from ESET comes to explain what is being done to correct this problem.

[Marcos 5,074]

28 minutes ago, New_Style_xd said:

What is making me more worried is ESET is not doing anything to identify and solve this problem, and no one from ESET comes to explain what is being done to correct this problem.

It was already explained, I quoted developers in my previous reply. In the future we'll rework the functionality to work around the issue caused by using the said Windows crypto API function.

[itman 1,659]

I spent more time last weekend doing more research/testing on this issue and I know now what the problem is. It is related to a certificate chain validation issue that has surfaced multiple times in past forum issues. Eset has to date ignored the issue. So, don't expect a fix now as I see it.

Some brief diagnosis info.. 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. That leads to the following findings.

First, there are two intermediate certs. in Firefox's Authorities certificate store that will lead to Eset Service memory spiking if one lands on a web site whose cert. is chained to one of the following:

Review of the DigiCert SHA2 Secure Server CA chain path data shows the following:

Notice something odd about the chain path? Notice that two root CA certs. are shown.

Closer examination of chained Digicert Global Root CA cert.. shows it has characteristics different for the same cert. present in Firefox's Authorities certificate store; primarily the chained cert. supports SHA2 versus only SHA1 that is supported for the Firefox's Authorities certificate store cert..

So what the hell is going here? Well, servers can download what can best be described as a "intermediate root cert." on demand and then chain this intermediate root cert. to a new root certificate. This is done when there are problems with the original issued root CA cert.. The problem here appears to be that Microsoft no longer allows for certificate revocation lists referenced in the web site issued cert. that use SHA1; namely this:

Quote

To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed.

https://en.wikipedia.org/wiki/Certificate_revocation_list

Referring back to my opening paragraph statement of "I know now what the problem is. It is related to a certificate chain validation issue that has surfaced multiple times in past forum issues," the problem is Eset "chokes" on the processing of intermediate root certs. thereby borking the entire chain validation processing.

Eset needs to fix this cert. chain processing issue ASAP!

In the interim, Eset needs to bypass any certificate revocation checking for any web site cert. that chains to the two above shown intermediate certs..

 

Edited February 15, 2022 by itman

[itman 1,659]

BTW - if you haven't figured out yet what is causing Eset Service memory spiking, I will explain that.

When Eset attempts to process a certification revocation list (CRL) from a web site cert. that is using one of the two Intermediate CA certs. referenced in my prior posting, it goes "spastic" and proceeds to "brute force CRL processing recovery mode." There is a noticeable pause in web site rendering in the browser. Eset appears to thinking to itself, what do I do now? I got it! I will load the entire Microsoft provided CRL into memory that contains all revoked certs. from all issuing CA's. 

Well, I could live with that for the time being. However, the correct way to do this would be to unload this aggregate CRL from Eset Service memory when the browser was closed.

But here's the problem. Once Eset loads the aggregate CRL into Eset Service memory, it will stay there until a system restart. Most use Win 10 fast startup mode which means the aggregate CRL remains in Eset Service memory, Far worse is the Microsoft provided CRL is updated daily via Win 10 crypto processing. However from what I can tell, this update is not carried over to what currently exists in Eset Service memory.

Edited February 15, 2022 by itman

[Marcos 5,074]

10 hours ago, itman said:

Well, I could live with that for the time being. However, the correct way to do this would be to unload this aggregate CRL from Eset Service memory when the browser was closed.

That's how the Windows crypto API function utilized by ESET to filter SSL works. Releasing the memory is not in the hands of ESET in this case as already explained.

[itman 1,659]

6 hours ago, Marcos said:

That's how the Windows crypto API function utilized by ESET to filter SSL works. Releasing the memory is not in the hands of ESET in this case as already explained.

Since Eset appears to be clueless on how to fix "intermediate" root cert. downloading by the browser, it needs to add Intermediate cert. revocation checking bypass exclusion capability. It would first check if a web site cert. chains to an excluded Intermediate cert.. If it does, Eset would bypass any cert. revocation processing for the web site.

If this isn't possible, 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..

Firefox is more than capable of performing this checking; more so if security.ocsp.required option is set to true. This will result in "hard failure" processing in regards to cert. revocation checking. That is if Firefox doesn't receive a revocation status response in 10 secs. from OSCP server, it assumes the cert. is revoked.

Edited February 16, 2022 by itman