As stated in the subject, Windows 10 update KB5018410 breaks currently functional SSL VPN connections.
Environment
Clients: Windows 10 Professional. SSL VPN connections using built-in Windows VPN client.
Server: Windows 2008 R2 using a self-signed certificate.
Problem Detail
The client workstations are able to attach to the SSL VPN and everything functions properly until KB5018410 is installed on clients on either of builds 21H1 or 21H2, at which point clients receive the message "client and server can't communicate because they don't possess a common algorithm". Removal of KB5018410 resolves the issue, but Windows Update must also be paused on the client computers to prevent reoccurrence from the update simply reinstalling.
Yes, I am aware that the destination VPN server is well past EoL. However, there's little my team can do about it since it's under the control of another entity for whom our organization does a very large portion of our work via the aforementioned SSL VPN. While I suppose it's possible that something changed server-side, I deem it extremely unlikely to be related since clients connect fine until KB5018410 is installed, cannot connect once it is installed, then connect again without issue once it's uninstalled and updates are paused.
Solutions Attempted Thus Far
Though "common algorithm" sounds more like a cipher, hash, or key exchange issue, I enabled all legacy version of TLS on the client computers via the appropriate registry keys to no avail: they still could not connect with KB5018410 installed.
I also used the IIS Crypto software from Nartac to explicitly enable all legacy cipher suites on several affected client workstations, which similarly failed to resolve the issue.
The only solution that works, at this time, is to manually uninstall KB5018410 and pause updates to prevent reinstallation.
I attempted to use the wushowhide utility to simply hide the offending update, but it doesn't find it in scans to hide it once it's been installed, doesn't find it to hide it while updates are paused, and has about a fifty percent success rate finding it to hide it if I resume updates and try to tag it quickly while KB5018410 is in the process of downloading/installing.
Any suggestions on other ways to block this thing? I have several dozen workstations on which it needs to be addressed, and pausing the updates until Microsoft resolves the issue is not the most desirable solution - I'd rather continue to get other updates and simply ignore this one.