the default certificate/key (conf/tls/server.cert.pem) even when that
cert is valid and issued by a trusted CA (like Let's Encrypt).
You would get such an incorrect "best practices advice" on-boot, but
(fortunately) not on each subsequent REHASH.
This was because the TLS system was not yet initialized completely at
the time of the best practices checks, ctx_server was NULL. This is
now solved by re-ordering some function calls.
This does change some win_error() and config_load_failed() stuff for
Windows so I hope that's okay.
Reported by Bun-Bun.
* In 2016 we switched from OpenSSL to LibreSSL because the OpenSSL
codebase was in a bit of bad shape and LibreSSL promised to be a
more modern codebase. Now, almost a decade later, OpenSSL has had
many code cleanups and is more security aware (code audits etc),
especially since OpenSSL v3 things are looking OK and it seems
LibreSSL doesn't have much progress nowadays. Which is understandable
as they have a lot fewer coders available but has an effect on things
like how long it took for TLSv1.3 to appear and for other new things
like PQC. It also seems like security fixes are now slower than
OpenSSL instead of the other way around. Anyway, I think they did their
job well (together with other people) in "triggering" the OpenSSL
project to get things back on track. Let's switch back now.
* For context: it seems several Linux distro's that used to do go for
LibreSSL have also switched back to OpenSSL.
* LibreSSL is still and will continue to be a supported library to
use with UnrealIRCd (especially with OpenBSD and FreeBSD in mind).
So, if there are any issues (compile problems, configuration problems,
some feature not detected), then please report it on our bug tracker
at https://bugs.unrealircd.org/ ! We will have to rely more on such
user-reports now that the main devs will likely only work with OpenSSL.
Also... i have cleaned up the Makefile.windows a bit to be more consistent
Hopefully i didn't make a mistake there...
[skip ci]
requests normally, unless the niche feature set::allow-user-stats is used)
The tld::motd was made optional in Jun 2022 commit 1fe6119026.
Not setting it is probably a bit rare, which explains why this bug was only
reported yesterday (Aug 2025) via the crash reporter.
Just in case someone thinks we are going to msg users on plaintext ports
by default, no we don't that, or at least not this year.
This is purely a "best practices" advice to admins on config load.
[skip ci]
Isn't that what it was supposed to do? Well, yes and no, previously
it only guaranteed that between reconnects (so the 2nd try not being
before class::connfreq than the 1st try), but there were no guarantees
for the first time period directly after a squit.
* When a netsplit happens and
[set::server-linking::autoconnect-strategy](https://www.unrealircd.org/docs/Set_block#set::server-linking)
is `sequential` (which is the default) or `sequential-fallback`
(which is a good value for leafs) then we now consistently wait for
[class::connfreq](https://www.unrealircd.org/docs/Class_block)
seconds before trying to connect to the (same or next) server.
By default this is 15 seconds in the example configuration
server class. The reason for this is to provide a consistent behavior.
Previously we waited semi-randomly for 0 to class::connfreq seconds.
The previous behavior caused the picking of 'next server to try' to
be inconsistent, which especially caused issues for `sequential-fallback`.
If you want quicker recovery times in case of a netsplit, simply lower
the value of [class::connfreq](https://www.unrealircd.org/docs/Class_block)
in your configuration file, e.g. to 5 instead of 15 seconds.
Oh yeah and for connect-strategy 'parallel' things stay as is, with
the wait of 0 to class::connfreq per-server, which seems fine for that.
Unless you want a 'BOOM!' effect of mass reconnects instantly, in
which case you can just set class::connfreq very low.
That is, if the set::best-practices::trusted-cert check is on and passed
("certificate is valid and issued by a trusted CA") then we also
do this new set::best-practices::trusted-cert-valid-hostname check:
/* If the trusted-cert check passes, then we do another check to see if
* the certificate is valid for me::name. Since users usually connect to your
* server by your server name it is important for the certificate to be
* valid for that name. Unless you really only care about e.g. irc.example.net,
* and not about individual irc2.example.net server names, in which case you
* can turn this off, but not sure if that is good practice.
*/
trusted-cert-valid-hostname yes;
Expired: this is a warning, not an error (we still want to boot the ircd)
Expired: handle the case for link::verify-certificate explicitly to avoid confusion
Ports that listen on 127.0.0.1 or ::1 are ignored (useful for e.g. services)
Looks like this:
[info] You have at least one IRC plaintext port open (such as 5668). Nowadays, everyone should be using SSL/TLS (on port 6697). See https://www.unrealircd.org/docs/Use_TLS.
See that https://www.unrealircd.org/docs/Use_TLS for more info (feedback welcome)
All this is in addition to somewhat related 29ce0ce29a:
[info] Your SSL/TLS certificate is not issued by a trusted Certificate Authority.
[info] It is highly recommended to use a 'real certificate'. To get a free one, see: https://www.unrealircd.org/docs/Using_Let's_Encrypt_with_UnrealIRCd
If applicable, that message is printed first, the 6667 one comes after ;)
Suggested in https://bugs.unrealircd.org/view.php?id=6500
and numerous times / discussions on IRC over the past years
It's finally time.. no.. it's overdue..
/* Standard IRC port 6667:
* Insecure plaintext (NOT for production servers)
* This listen block is here only for quick testing.
* Delete or comment out this listen block on production servers
* and use TLS on port 6697 instead.
*/
Also throw it in translated example*conf's (in English),
the translators can translate it.
one could possibly miss this cert verification warning. And since
that will later become an error, it is even more important to
notice such a (hopefully unusual) case quickly.
On the incoming side it was correctly identified as link sec 2,
but on the outgoing side the localhost check failed and caused link sec 1 or 0.
Bug has beent here for a while but I don't think many people
link two UnrealIRCd servers over localhost that are on production
(i do, when dev'ing, but then I don't care about linksec, obviously)
Also, this wouldn't flag services from 2 to 0 because this bug only
affected outgoing UnrealIRCd server connections.
not verified. This changes the wording from "You may want to consider" to
a warning, makes it more strong and that in the future we will reject this
by default.
Actually still pondering to reject it now already by default, but let's start
with this commit first...
Is same as baseline.txt but with this line added:
+"FS_KEMs","127.0.0.1/127.0.0.1","5901","OK","X25519MLKEM768","",""
This so debian 13 test succeeds (and other future distros with OpenSSL 3.5+)
* [set::tls](https://www.unrealircd.org/docs/TLS_Ciphers_and_protocols):
Rename `ecdh-curves` to `groups` (the old name will continue to work)
* Add (and prefer) the `X25519MLKEM768` hybrid group, which is a mix
of `X25519` that is commonly used today and quantum-safe `ML-KEM-768`.
This to protect against
["harvest now, decrypt later"](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later).
* To benefit from this, OpenSSL 3.5.0 or later (released April 2025)
is required on the server, and similarly a client that supports this.
At the time of writing, almost all Linux distros don't have such an
OpenSSL version yet (which is not a problem, this new feature will simply
not be available). Notably Debian 13 (when released in August
2025) will have it. LibreSSL does not support it either yet, so our
Windows build does not have this feature.
* Also, change the TLS information on-connect and in WHOIS etc. from
something like `TLSv1.3-TLS_CHACHA20_POLY1305_SHA256` to
`TLSv1.3/X25519/TLS_CHACHA20_POLY1305_SHA256`. In other words: using
slashes as separators and showing the group / key exchange in the middle.
The group is only shown on newer OpenSSL versions. If someone would
use the new PQC hybrid group mentioned above then their TLS info would
start with `TLSv1.3/X25519MLKEM768/`.
* TL;DR: better secrecy against future quantum attacks, even though
not many clients or servers support it at the moment.
[skip ci]
Previously this was like:
TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
It is now changed to be like:
TLSv1.3/X25519/TLS_CHACHA20_POLY1305_SHA256
So:
* Changed from '-' to '/' because sometimes the cipher(suite)
contains a hyphen (TLSv1.2 and earlier)
* Show the key exchange "group" in the middle, such as X25519
for the usual non-PQC case and X25519MLKEM768 for hybrid group
with PQC.
* The group is shown in OpenSSL 3.0.0+ (and obviously you need
OpenSSL 3.5.0 to ever see X25519MLKEM768 there, but that is
something different)
[Channel flood protection by default](https://www.unrealircd.org/docs/Channel_anti-flood_settings):
This is an important change that IRCOps and chanops should know about:
* By default we now apply the anti-flood profile "normal", which should be fine for most channels.
* If a chanop does not want this they can override this by setting
`MODE +F` with [another profile](https://www.unrealircd.org/docs/Channel_anti-flood_settings#Channel_mode_F_profiles).
* For example, for a channel with hundreds of users and lots of activity
`+F relaxed` may be more appropriate. Or, chanops can turn anti-flood
off entirely by setting `+F off`
* The reason for this change is that many admins and chanops in practice
don't seem to use `+f` or `+F`. With this change they are now protected "by default"
when no MODE `+f` or `+F` is set.
* Advanced users can can grab the detailed effective settings with `MODE #test F`
(there will be an error if you use `cloak_md5`, but everything
will work fine if you use `cloak_sha256`).
We phased out MD5 usage years ago, so it is only contained to
the old cloaking module. In fact that was the only reason we
started to provide the SHA256 cloaking module, simply so it
isn't using old MD5.
Of course, for module coders this means they should not call
DoMD5() or md5hash(), but that would be rare. Currently zero
modules in unrealircd contrib do this and it makes no sense
to start using it nowadays anyway.
Since UnrealIRCd 6.0.0 when a server connects, we like to drop the
existing link so they don't need to wait on "Ping timeout".
However, that goes against the JUPE stuff that Services tend to use,
it basically negates it.
We now check if the uplink is u-lined (like for services) and if that
is the case we deny the link with "Server Exists (Juped)". So just
like before U6, and with a slightly more helpful message even.
Reported by Jellis in https://bugs.unrealircd.org/view.php?id=6498
We now expire after 30d if score is <12 (so 1 hour of being online)
and we expire after 90d regardless of score.
Note that for this to work, all servers would need to be running
UnrealIRCd 6.2.0+ because when a score for an IP is still present
on any of the servers on a network, and a user with that IP connects,
then the score will be broadcasted from the server that still has
the score and it will be re-added by all servers with that score.
But eventually it should be like this... :D
Reported by armyn in https://bugs.unrealircd.org/view.php?id=6536
are not (always) affected by this. We now check if there is any client port
exposed (to non-localhost). So if you have a hub with no client ports or
only at localhost then you won't get this bestpractices advice.
And also fix compile error on OpenSSL < 1.1.0 (undeclared var, duh)
suggest to use Let's Encrypt.
This can be turned off via set::best-practices::trusted-cert, see
https://www.unrealircd.org/docs/Set_block#set::best-practices
Oh yeah, and this only works at OpenSSL 1.1.0 and higher, i didn't bother
with people running ancient versions.
Bram Matthys