Forums Connection Issues Unable to connect to server (SSL wrong version num

Been over a year of receiving this error message. It affects half of EFNet servers. I have no means of debugging it at my disposal.

* Unable to connect to server (SSL wrong version number)

See here.

I guess if you follow the chain of links, you will see that it might be possible to re-enable the cipher type that EFnet is using and make it work. If you want to connect to EFnet anyway, given that the alternative is a non-encrypted connection, it can be argued that any encryption (however compromised) is better than an unencrypted link.

You will need to investigate the ciphers present in the EFnet certificate to know what cipher type(s) to enable.

If only I could see some sort of debug messaging to understand why this is sometimes and not all the time. Why doesn't mIRC at least tell me the SSL cipher the server is demanding I use, or is capable of using, or that I attempted to use but failed.

Very likely because you are using the round-robin server address. This means that you are cycling through different servers on the EFnet network, some of which are using out-of-date ciphers and protocols.


The server chooses from the cipher list that the client presents. If the server can't find anything it likes, it returns an error. The only way to know what the server supports is for the client to build a list of ciphers it supports internally and to connect to the server using each one individually to see which are accepted or rejected.

mIRC's set of allowable ciphers and protocols is set at such a low level, to allow connections to old IRC servers that have not been updated in years, that if the server you are trying to connect to is not accepting them, you may as well not be using SSL.

That is the reason why mIRC's server list does not include SSL servers for EFNet.

mIRC should really be using a stricter default cipher list. As I mentioned here, the cipher list was last updated in 2014.

It is on my to-do list to review the default cipher list, as well as the servers list, to determine which networks are acceptable for use with SSL.

What is the status of this issue? I am actually running an unreal ircd, and without any changes to my server or client settings, this error is happening:


We have seen this "sporadically"; meaning, sometimes it works fine. Can you enable some better logging so this can be fixed? The error message is completely un-helpful (and inaccurate)

There is no status because this is not an mIRC issue as far as I can tell. The error being reported, while unhelpful, is actually what OpenSSL is reporting. The reasons for this error, and the simple error message, are explained in my above post.

I also mentioned above that mIRC should really be using a stricter set of modern ciphers and protocols. However, if it did that, even more users would see the issue, which is due to servers using old, broken protocols and ciphers that are no longer safe to use - the servers need to be updated to use newer, safer ciphers and protocols.

What IRCd/openssl version are you using?

Can you enter this in your status window and paste the output?



My copy:


[11:10:59] UnrealIRCd-6.0.0-beta4. kindone.foobar.net Fhn6OoEmM [Linux laptop 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64=6000]
[11:10:59] -kindone.foobar.net- OpenSSL 1.1.1k 25 Mar 2021
...

UnrealIRCd-5.2.2.
OpenSSL 1.1.1j 16 Feb 2021

I restarted the server side last night, I think it washosed because of a bad time/date issue. I'm going to keep an eye on it.

Now that options/connect/options/ssl has a box for editing the ciphers list, I thought I'd take a stab at seeing if an obsolete cipher is the cause of the efnet certificates being seen as invalid.

I changed the setting to show me invalid cert for approval, so when I first connected to irc.efnet.org I see an error message saying "Name is not valid or does not match server name", which I assume is because the roundrobin hostname is not also on the certificate. So I connect directly to the servername from the editbox, and it's still telling me the cert is invalid. But it no longer has the same error message about the name. This time it's just the cryptic warning "Your connection to the server is encrypted, however there is a problem with the server's security certificate."

And this same behavior is happening at all their servers that I tested, so whatever is the cause, it's probably from something they're doing that's being setup the same way at all their servers. They no longer have expired certificates, so that's not the problem.

To test whether the problem is caused by an obsolete cipher, I edited the cipher list down to only "ALL:!aNULL" and was planning to add back ciphers to the exclusion list until it was invalid again, but that didn't work, because I was never able to get the certificate seen as valid even from this simplistic setting.

So, either the cause of invalid efnet certificates is not due solely to an obsolete cipher, or the new options box is not actually updating the ciphersuite used for the SSL connection.

Another possibility is that OpenSSL eventually removes ciphers from their approved list, so even if you remove RC4 from the exclusion list, if mIRC is using an OpenSSL that was compiled with the obsolete ciphers disabled, the SSL handshake would still fail because mIRC's side of the handshake can no longer speak the old cipher's lingo.

Are they using self-signed certificates?


You'll be pleased to know that it is :-]

Yes looks like they're self-signed. Do they need to get a cert through letsencrypt or similar in order to prevent that?

Summary
Self signed certificate

Issuer
Organization: Swepipe
Host: irc.swepipe.se
Country: SE

Subject
Organization: Swepipe
Host: irc.swepipe.se
Country: SE

Valid from 18/05/2021 to 16/05/2031

SHA512 fingerprint:
4D:0D:E4:3D:0E:DE:23:9A:7C:29:3B:88:58:4B:00:F1:84:98:9F:15:DE:DA:3F:A6:BA:AF:DE:3F:CF:94:79:95:97:70:A6:F6:0A:3D:E4:35:C3:8E:05:42:A8:4F:79:FF:61:BF:61:3A:7F:8C:93:B2:AA:12:0C:27:36:31:8E:2E

Yes, they would. I believe one of the reasons that some networks are still using self-signed certificates and haven't moved to Let's Encrypt is that it takes a lot more work to get multiple, volunteer server hosts to synchronize their SSL certificates.