These are feature requests related to user-created certificates, a topic of which I admit my knowledge of the topic is limited. But there's not much on this forum discussing them. Some of these changes might be bordering on bug fixes.
1. Not sure which is the simplest way to extend $sslcertsha256 to support other hashes. SwiftIRC uses the sha256 fingerprint returned by $sslcertsha256, but Libera.Chat wants to know the sha512 fingerprint instead. Even though I never set up a NickServ account at Snoonet, /whois showed me the md5 fingerprint of the certificate I'd just created before I connected to them, and I didn't have the login method set to SASL External, so I'm assuming that's the fingerprint they want for SASL External. Maybe allow $sslcertsha256 to have an optional parameter where we can give it another hashname, and the default is sha256 without it?
$sslcertsha256(md5) $sslcertsha256(sha512) etc
The need for a new identifier may not be critical since many networks supporting SASL External have the /whois reply show us the fingerprint of the certificate we're broadcasting when we connected. But Rizon's /whois just tells us that we're using a client certificate without showing us the fingerprint. And, at Libera we can use "/NickServ cert add" and it will automagically add the fingerprint for the certificate broadcasted when we connected.
2. Could there be documentation in /help for how to use the certificate mIRC creates? The F1 /help has little mention of certificates, with the topic for the connect/options/SSL dialog linking to a webpage that makes no mention of certificates.
3a. The SASL External protocol does not use the NickServ password like SASL Plain does, so the password box below the 'Login method' in the serverlist editor should have the password grey'ed out unless the dropdown is selecting one of the other 3 choices who actually do use the password.
3b. The box for entering the password, below the 'Login Method' dropdown, shows only bullet symbols when inputting the password, so I'm sure many SASL Plain users would find it helpful if there were a checkbox to the side of the dialog which could be checked to see the password text while entering it. I understand there can be security reasons for not showing the password that's been previously entered, but at the very least it could allow people to see the password while it's being entered. That avoids people 'solving' the problem by typing their password into an editbox so they can inspect it before copypasting it in the entry box.
4. After being confused for a while, I finally figured out that SASL External apparently doesn't work if connecting to a non-SSL port, so it would help avoid user confusion if that were included in any /help documentation about certificates, and/or giving an FYI message when saving the serverlist edit while the port/login-method don't appear to be compatible.
5. When having mIRC create our certificate instead of using OpenSSL.exe directly, is there a mirc.ini setting to allow people to define the RSA key size for the certificate that mIRC makes?
The CertFP instructions at Libera.Chat is asking people to create an RSA 4096 certificate, but as far as i can tell, mIRC creates only 2048's - though Libera will accept those. I'm guessing the 2048 choice is a 'one size fits all' that a larger group of networks on the serverlist will support.
6. It would be great if the serverlist editor allows entering a local certificate that overrides the universal certificate that was created in connect/options/SSL, or a serverlist checkbox to prevent the universal certificate from even being broadcast to specific networks.
It appears that, once we've configured mIRC to have a universal certificate, the only choices are to allow that universal certificate to be broadcast to all other networks, or use the /server -k scripting command to override that by telling it to broacast a different local certificate to that network, or to avoid using an SSL port because that blocks the certificate from being enabled at that network - though the public certificate may or may not be sent to the server in the failed handshake.
With this behavior of not letting us connect to any SSL port without broadcasting a certificate, once we've isntalled a universal certificate that we're only using at 1 network for SASL External, it allows us to be fingerprinted so all other networks can identify us across repeated visits regardless of which IP address or nick we're using. In effect it creates a universal cookie that all networks can see.
Currently, this can be avoided only with the /server command, and only partially.
/server servername +port -l external -k filename.pem
... lets us use a local certificate at that network while a different network uses the universal certificate, but I don't see anything in the serverlist editor which lets us do the same. While a universal certificate has been installed, these following attempts to block it from being used at 1 specific network all fail.
This attempt halted the script:
/server servername +port -k NoSuchFile.pem
This attempt didn't halt the script, but it refuses to connect at all:
/server servername +port -k FileWithoutCertificate.pem
This attempt just ignored the -k switch and used the universal certificate:
/server servername +port -k
Probably the last one is the most appropriate syntax which would connect to an SSL port without broadcasting any certificate at all, since the intent of using -k is obviously to not want to use the universal certificate.
If it's considered a problem that using -k %variable could have unwanted results due to the variable being $null, that could be avoided by using $$+(%variable) or by using a different switch following -k %variable, which causes a missing -k parameter to trigger a syntax error
So it seems the only way to have an SASL External certificate used by 1 network without forcing all other networks using a +SSL port to broadcast a certificate is to have mIRC create a certificate, where the menu immediately tries to use it as the universal certificate. We'd then clear that certificate from being displayed in the options menu as the universal certificate. Then, we can't connect to that 1 network using the serverlist, and must instead use a script in order to connect to them using /server -k file.pem
I know there can be uses for broadcasting certificates other than for SASL External. I once had admin privileges at a network, where the OPER command wouldn't work unless I was connecting from a specific IP address. I'm guessing by now the ircd's have settings to use a certificate to validate us instead. However, that shouldn't be a reason for all other users to broadcast the certificate 'cookie' to all other networks too.
Since a local certificate would be server related, it seems more appropriate for that to be kept in the serverlist instead of mirc.ini, probably in a new [section] of servers.ini, where there would be new choices to either define a local certificate for that network, or to avoid having the universal certificate being broadcast to that network, which I'd think should be the default choice anyway.
