MMx

There's a CRL on the same URL with about the same size and a newer expiration date. Do you still experience the same issue?

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.

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.

Yes, I've written a detailed analysis here: https://forum.eset.com/topic/31282-memory-usage/page/4/#comment-147108 In a nutshell, this memory is occupied by Windows Crypto API cache that we don't have direct control over. I'm currently trying to figure out if it can be configured beforehand.

I see no AV criticism in the linked article or in your post. Also we're not using HTTP Public Key Pinning nor certificate pinning. Can you explain the relevance to the topic here?

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

Thanks everyone for providing the dumps, using them we now have a theory about what is hapenning and a potential fix. It would be helpful if you could test it. To do that first disable all workarounds (like app verifier, enable startup scan) then download the appropriate zip file attached to this post. If you have a directory called "c:\Program Files\ESET\[product name]\Modules\em005_64" then cleaner_test_dll_64bit is for you. Unpack the file into "c:\Program Files\ESET\[product name]\Modules" (not into the em005_64 subdirectory) with selfdefense disabled and reboot. If you have a directory called "c:\Program Files\ESET\[product name]\Modules\em005_32" then cleaner_test_dll_32bit is for you. Unpack the file into "c:\Program Files\ESET\[product name]\Modules" (not into the em005_32 subdirectory) with selfdefense disabled and reboot. If you have a file called "c:\Program Files\ESET\[product name]\em005_32.dat" then you need to use cleaner_test_dat_32bit.zip. Unpack it into "c:\Program Files\ESET\[product name]\" replacing the existing file with selfdefense disabled and reboot. Then report back if the problem is fixed. cleaner_test_dat_32bit.zip cleaner_test_dll_64bit.zip cleaner_test_dll_32bit.zip

I'd like to clarify Marcos' post. You can find the app verifier installer here 32bit: https://drive.google.com/file/d/1c4wQGJteGQb5EurEmhYaYLcmAqUbAIY-/view?usp=sharing 64bit: https://drive.google.com/file/d/1Sh_Yyp7Ie69dbGqBaitN_Nv5iAzuRdwb/view?usp=sharing Before you are able to use it, you'll have to disable self-defense and reboot. The changes you make will be applied after you click Save in the verifier and restart ekrn by rebooting Windows. You can skip the manual registry import he's describing by extracting and importing the file attached to this post. Dumps will then be created in c:\dumps. Edit: There's one more option that needs to be changed in the app verifier. After you've added ekrn.exe you'll need to expand Basics, right-click Heaps, Properties, and enable UseLFHGuardPages (see attached screenshots). local_dumps_registry.zip

Thank you very much RCK for the dumps, they have been helpful. Unfortunately by the time they were created too many things have gone wrong to figure out what was the primary cause and was just a result. It would be helpful if you (or anybody else) could run the following command as admin as soon as possible after boot procdump -ma -e 1 -n 10 ekrn.exe Then replicate the problem, and send us all the dumps that will be created. Procdump can be downloaded from https://docs.microsoft.com/en-us/sysinternals/downloads/procdump. Edit: Please disable selfdefense and reboot before using the procdump command, otherwise it would fail.

Also please note that supporting HTTP/2 means implementing full client and server functionality as specified by standards. This isn't directly related to certificates, and changing the TLS handshake to advertise HTTP/2 support is one of the easiest things to implement.

That might work in your case, but we try to tune our solutions to work for the majority of around 100 milion of our users. In particular we detect streams and avoid writing them to disk altogether. It's possible that the server in your case is using some less common ways to present the stream to you which our detection doesn't recognize. To investigate further it would help if you could let protocol filtering logging run for a couple of minutes while the temp files are being created: Enable F5 -> Tools -> Diagnostics -> Enable Protocol filtering advanced logging Make sure the temp files are being created, wait a while Disable the logging Send me the files "c:\ProgramData\ESET\ESET Internet Security\Diagnostics\*.pcapng"