edit: just to be clear, if you have mirc.exe in a different folder than mirc.ini, which i don't have, you might need to copy the dll's into the folder where mirc.exe is located instead of where mirc.ini is located
I'm curious what you mean about your channel needing OpenSSL 2+? There is no such animal as OpenSSL version 2, as they jumped from 1.1.1 to 3.0. Are you trying to use a DLL that's been compiled to work only with v3.0?
You're saying $sslversion is 184.108.40.206 which is OpenSSL 1.1.1i, which was used only for mIRC v7.64, while v7.72 uses 1.1.1s which should show 220.127.116.11, so if you're still seeing the 18.104.22.168 it could be caused by having the libcrypto-1_1.dll and libssl-1_1.dll from 1.1.1i copied into your mIRC folder. The 1.1.1 series is at 't' now, and I'm pretty sure that you can copy the dll's from 1.1.1t into the mIRC folder and have the identifier change to say 22.214.171.124 and have everything work right, but you won't be able to do that with OpenSSL 3.0 even if you rename their DLL's to the filenames that mIRC is looking for.
It was v7.56 where mIRC updated from the 1.0.1 series to the 1.1.1 series, and at that time a DLL I was using couldn't work anymore until the author compiled it using 1.1.1 instead of 1.0.1, and people using mIRC v7.55 and earlier compiled under 1.0.1 series can't use the updated DLL which uses the OpenSSL 1.1.1 DLL.
Khaled has described it being a lot of re-coding to change mIRC from 1.0.1 to 1.1.1, and from my interacting with that external DLL, I know that it was not a matter of simply hot-swapping the newer OpenSSL dependencies in place and pressing the compile button, as there were a lot of changes that needed to be made to the code to get that DLL's calls to/from OpenSSL working right.
And that DLL's changing from 1.0.1 to compatible-with-1.1.1 code also needed testing, because the "this now works" code was not always "this now works correctly always", and I'm sure the same thing would happen after changing mIRC code to work with 3.0. The OpenSSL code for v3.0 made changes to a lot of things internally, but kept the external functions using identical parameters as 1.1.1 even though they didn't actually continue doing the same thing 'under the hood'. A lot of these changes were the kind of 'we know better than you what your code should be doing' changes, so stuff either stopped working or now took an outrageous amount of time. A couple of examples of OpenSSL doing stuff like this:
1. OpenSSL client certificates. When mIRC makes RSA certificates in options/connect/options/SSL it creates them in PEM format. OpenSSL also has a PFX format that the PEM can be translated into, however the PFX format defaults to wanting to have a password. This would be a big pain to have in your IRC client certificate, where you come back to the keyboard to find that you've been offline for hours because there's a prompt waiting for a password input. When using 1.1.1 series, it's easy to export from PEM format to PFX format without using a password. But for 3.0 series the same syntax no longer works without the -legacy because they don't think users should be using a key in PFX format without it having a password, and who knows if OpenSSL will eventually start doing the same to PEM format too. mIRC has support for a lot of past operating systems, and each newer OpenSSL keeps shoving more of their stuff into the 'legacy provider', making it harder to keep that code working with the newer series.
2. Checking if numbers are prime. Under 1.1.1 you can specify how many rounds of Miller-Rabin you wanted to use in testing if a number is prime, however in OpenSSL 3.0 they eliminated the setting where you could specify the number of Miller-Rabin repeats. But instead of eliminating the parameter in the external function call so that coders could now be alerted that OpenSSL was not honoring their request, they kept the same external interface as 1.1.1 - but just silently ignored the reqested number of checks, and it instead does the number of checks they decide you should have, based on how big your number is, which for the RSA-4096 client certificate would now be 128 repeats.
So, for example, if mIRC were to use code that each time you connect to a network using a client certificate, when it loads the client.pem, it were to check if the primes in the private key really are primes, a request to perform 2 or 3 rounds of Miller-Rabin would now suddenly take 30 seconds because it was silently ignoring your request for 3 rounds and instead doing 128. When I asked OpenSSL to restore the 1.1.1 functionality in 3.0, they wouldn't do it because they want to prevent people from mis-using the parameter. While something like this would be obvious the first time anyone tried to connect using a client certificate, there could be other problems which could make v3.0 bomb out or take too long, but might be encountered only under edge case conditions, or could randomly happen only 1/256 of the time. In my case, if I were to upgrade my program from using the 1.1.1 DLL to using the 3.0 DLL, there's no way I could keep my code from being 3x slower or worse, due to just that 1 external function ignoring that 1 parameter.
Last edited by maroon; 09/03/23 04:04 PM.