MMx

Back to the original topic.
We've had a discussion with Microsoft regarding this. They believe that the memory and CPU usage reported here is adequate to the size of the revocation list that is being processed. There are no plans to implement any changes in this part of Windows unless they are required for security. In their words it's not possible to avoid this behavior except disabling the cache which is not recommended.
I've identified some circumstances that were contributed to this problem. This will be solved in protoscan 1439. Unfortunately the problem might come back anyway since it's considered a normal behavior of Windows, although now it will be less likely.
It's possible to apply this workaround manually. To do that create a DWORD registry value called CryptnetCachedOcspSwitchToCrlCount under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\Config (you may need to create several missing path components) and set it to 1047 (the special meaning of this value is that it will be reverted to default when the product is uninstalled). Then run the following commands elevated and reboot:
certutil.exe -urlcache http://crl3.digicert.com/ssca-sha2-g6.crl delete
certutil.exe -urlcache http://crl4.digicert.com/ssca-sha2-g6.crl delete
This needs to be done for each user separately.
It is also possible to completely disable the cache that is causing these problems. Doing it means that verifying certificates after reboot will be as slow as it is the first time they are encountered ever. This is not a recommended solution:
certutil -setreg chain\ChainCacheResyncFiletime @now+10000:0
To revert this use
certutil -delreg chain\ChainCacheResyncFiletime

Back to the original topic.
We've had a discussion with Microsoft regarding this. They believe that the memory and CPU usage reported here is adequate to the size of the revocation list that is being processed. There are no plans to implement any changes in this part of Windows unless they are required for security. In their words it's not possible to avoid this behavior except disabling the cache which is not recommended.
I've identified some circumstances that were contributed to this problem. This will be solved in protoscan 1439. Unfortunately the problem might come back anyway since it's considered a normal behavior of Windows, although now it will be less likely.
It's possible to apply this workaround manually. To do that create a DWORD registry value called CryptnetCachedOcspSwitchToCrlCount under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\Config (you may need to create several missing path components) and set it to 1047 (the special meaning of this value is that it will be reverted to default when the product is uninstalled). Then run the following commands elevated and reboot:
certutil.exe -urlcache http://crl3.digicert.com/ssca-sha2-g6.crl delete
certutil.exe -urlcache http://crl4.digicert.com/ssca-sha2-g6.crl delete
This needs to be done for each user separately.
It is also possible to completely disable the cache that is causing these problems. Doing it means that verifying certificates after reboot will be as slow as it is the first time they are encountered ever. This is not a recommended solution:
certutil -setreg chain\ChainCacheResyncFiletime @now+10000:0
To revert this use
certutil -delreg chain\ChainCacheResyncFiletime

Back to the original topic.
We've had a discussion with Microsoft regarding this. They believe that the memory and CPU usage reported here is adequate to the size of the revocation list that is being processed. There are no plans to implement any changes in this part of Windows unless they are required for security. In their words it's not possible to avoid this behavior except disabling the cache which is not recommended.
I've identified some circumstances that were contributed to this problem. This will be solved in protoscan 1439. Unfortunately the problem might come back anyway since it's considered a normal behavior of Windows, although now it will be less likely.
It's possible to apply this workaround manually. To do that create a DWORD registry value called CryptnetCachedOcspSwitchToCrlCount under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\Config (you may need to create several missing path components) and set it to 1047 (the special meaning of this value is that it will be reverted to default when the product is uninstalled). Then run the following commands elevated and reboot:
certutil.exe -urlcache http://crl3.digicert.com/ssca-sha2-g6.crl delete
certutil.exe -urlcache http://crl4.digicert.com/ssca-sha2-g6.crl delete
This needs to be done for each user separately.
It is also possible to completely disable the cache that is causing these problems. Doing it means that verifying certificates after reboot will be as slow as it is the first time they are encountered ever. This is not a recommended solution:
certutil -setreg chain\ChainCacheResyncFiletime @now+10000:0
To revert this use
certutil -delreg chain\ChainCacheResyncFiletime

This method doesn't allow to inject data into the connection. This has several disadvantages:
No blocking pages (it's much easier to figure out which tab a message is related to if its displayed directly in the tab than in a separate dialog), no redirects for Banking & Payment protection. There's no way to implement HTTP2 flow control properly since we would be unable to send any messages: "Flow control is specific to a connection. Both types of flow control are between the endpoints of a single hop and not over the entire end-to-end path." (https://datatracker.ietf.org/doc/html/rfc7540#section-5.2.1) This could have unforeseen consequences. There's also no way to send HTTP2 RST message to inform the browser that it shouldn't use any data it has received so far. If an HTTP2 response is completely tranfserred but we haven't finished scanning it yet, we are only able to delay the entire connection, blocking access to other resources which the browser could be parsing in the meantime. This would result in degraded performance. This might be one of the reasons why Avast slows down your browsing more than ESET (see Slowing-down when launching popular websites):
https://www.av-test.org/en/antivirus/home-windows/windows-10/december-2021/eset-internet-security-15.0-211609/
https://www.av-test.org/en/antivirus/home-windows/windows-10/december-2021/avast-free-antivirus-21.9-211603/ As already mentioned this research is couple of years old. Most of the findings there related to ESET were fixed before the paper was published (we were contacted by the author beforehand), all of them are fixed by now, some were never correct in the first place. Unfortunately the author didn't respond to our request for corrections or updates.

This method doesn't allow to inject data into the connection. This has several disadvantages:
No blocking pages (it's much easier to figure out which tab a message is related to if its displayed directly in the tab than in a separate dialog), no redirects for Banking & Payment protection. There's no way to implement HTTP2 flow control properly since we would be unable to send any messages: "Flow control is specific to a connection. Both types of flow control are between the endpoints of a single hop and not over the entire end-to-end path." (https://datatracker.ietf.org/doc/html/rfc7540#section-5.2.1) This could have unforeseen consequences. There's also no way to send HTTP2 RST message to inform the browser that it shouldn't use any data it has received so far. If an HTTP2 response is completely tranfserred but we haven't finished scanning it yet, we are only able to delay the entire connection, blocking access to other resources which the browser could be parsing in the meantime. This would result in degraded performance. This might be one of the reasons why Avast slows down your browsing more than ESET (see Slowing-down when launching popular websites):
https://www.av-test.org/en/antivirus/home-windows/windows-10/december-2021/eset-internet-security-15.0-211609/
https://www.av-test.org/en/antivirus/home-windows/windows-10/december-2021/avast-free-antivirus-21.9-211603/ As already mentioned this research is couple of years old. Most of the findings there related to ESET were fixed before the paper was published (we were contacted by the author beforehand), all of them are fixed by now, some were never correct in the first place. Unfortunately the author didn't respond to our request for corrections or updates.

It's the only way to catch exploits targeting browsers before they have a chance to run.

Just a quick heads-up, we've been made aware of a malware campaign that hosts malicious payloads as images in imgur.com, so we're removing it from the list of domains for which TLS filtering is skipped. That means it won't behave as described in previous posts anymore.

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.

I tried to understand your reasoning to the best of my ability and I believe you've made one key mistake.
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:
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.

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?
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