High CPU usage, can't connect, program won't quit

[ijnmko]

OS: Win10 x64, v1909
Specs: i5-3570K (4c), 16GB RAM, Radeon R9 285

I have come across a weird issue: FileZilla will open normally, but I am unable to connect to any FTP or fully close the program. By testing many released versions, I was able to track the starting point to version 3.36.0-rc1.

In version 3.36.0-rc1, FileZilla will start normally, and as soon as I try to connect to any FTP server, it will go to about 25-30% constant CPU usage on my quadcore CPU, and never finish connecting. I am unable to stop the connection attempt (the disconnect button is clickable but does nothing), and when I quit the program, the window will disappear, but it's still running in the background, still stuck at 30% CPU until I kill it via the task manager. From the server side, a connection attempt is seen and reaches "234 Using authentication type TLS" but then just stays there until the client is killed.

In version 3.47.2.1 (currently latest) the behavior is slightly different in that the high CPU usage starts right when FileZilla is launched, but other than that the problem presents itself identically to version 3.36.0-rc1.

Version 3.35.2 works just fine, and every version after this is affected by the problem. The problem has persisted through all OS updates since 3.36.0-rc1 was released back in 2018.

Looking at the changelog of the first version that shows the error, these are the official changes:

• Ask for explicit confirmation prior to falling back to insecure plaintext FTP if a server refuses to use TLS

• Warn if an FTP server refuses TLS that is known from previous connections to be capable of TLS

These changes don't look to me like they'd be related to the issue, so I assume that there has been some under the hood change that didn't make it into the changelog.

[Tim Kosse]

For some reason your system's trust store has insanely huge certificate revocation lists. It can take minutes to hours to parse those.

Find out why your system has such large CRLs.

[ijnmko]

Thank you for the hint! You are right in that it's caused by the CRLs, since the problem vanishes when I delete all the CRLs via the certmgr. However, that doesnt seem like a very sensible solution to me (it was just a test, restored from backup after this). I wouldn't expect you to troubleshoot why I have many CRLs, but they are by no means an insanely huge amount. It's like 40 CRLs and most are empty, the total number of single revoked certs over all CRLs is maybe 300 at most, which I wouldn't consider insane at any rate.

Maybe I am understanding this wrong, but are you saying that people who - for whatever reason, be it avoidable or not - have more than just a handful of revoked cert entries on their machine, just plain shouldn't use FileZilla?

And please, consider this: I use FileZilla to connect almost exclusively to servers that use self-signed certificates. I am not sure why FileZilla even tries to parse all of the system's CRLs when necessarily, 99% of that work is going to waste pretty much all of the time. Why not just follow the CRLs for the certs FileZilla actually encounters?

Again, thank you for your effort.

[ijnmko]

Reopening because while the resolution hit the right spot, it wasn't an edge case as much as was speculated -> more people are bound to be running into this problem.