People should preferrably go through the example conf line by line, but
if they are in a hurry or just want to get started quickly initially they
could CTRL+F on that.
because we send 9 character uids. However, IDLEN is defined as 12 so it is
natural for other people (services and other pseudo server writers) to assume
you could send 12, which failed until now, as it only accepted 11 characters.
Just to be clear:
* We generate and send 9 character uids in UnrealIRCd ourselves, this
works perfectly fine
* In 114d54ac61 in 2021 (UnrealIRCd 5.2.1) i
enlarged the buffers to allow INCOMING ids of up to 12 characters.
The reason for that is that I want the option to allow slightly larger
uids and could start doing that several years later without causing
desynchs and other problems.
* That didn't work properly, it only allowed up to 11 chars at this point.
* From now on it allows 12 chars. I do NOT recommend sending that though, if
you want to send bigger ids from your services/pseudo server then use
11, or... actually just use 9 like in normal unrealircd traffic at the
moment.
Reported on IRC by craftxbox
I was dumb: with an RSA cert you need ECDHE-RSA-* and i had
only included ECDHE-ECDSA-*. Long story short: TLSv1.2 didn't work
if you had an RSA certificate. Reported by BlackBishop, and in
hindsight also by Mi_92. Thanks for the quick reports, this should
be a quick fix :-)
pub rsa4096 2024-11-18 [SC] [expires: 2030-11-17]
36E6F65706E36B0937280299101001DAF48BB56D
uid UnrealIRCd releases and patches (for verification of software downloads only!) <releases@unrealircd.org>
The old key is still valid until 2025-06-29:
pub rsa4096 2015-07-02 [SC] [expires: 2025-06-29]
1D2D2B03A0B68ED11D68A24BA7A21B0A108FF4A9
uid UnrealIRCd releases (for verification of software downloads only!) <releases@unrealircd.org>
The new key is signed by the old key and uploaded to keyserver.ubuntu.com.
The old key will still be used for signing releases for now. Somewhere around
the summer of 2025 i will switch to the new key.
Posted in https://forums.unrealircd.org/viewtopic.php?t=9397 for transparency
For reference, the established TLS connections at irc*.unrealircd.org
over the past 6 months were:
14379 TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
368 TLSv1.2-ECDHE-ECDSA-AES256-GCM-SHA384
160 TLSv1.2-ECDHE-ECDSA-CHACHA20-POLY1305
3 TLSv1.3-TLS_AES_256_GCM_SHA384
There is nobody connecting with AES CBC in those statistics
(ECDHE-ECDSA-AES256-SHA256 and ECDHE-ECDSA-AES128-SHA384)
and set our default ciphers and ciphersuites. Note that by default in
UnrealIRCd 6 the built-in (non-cURL) implementation is used for remote
includes, which already uses the same defaults since 6.0.0. Also note
that most distros, like Ubuntu and Debian, already disabled TLSv1.2
in the default openssl conf and thus it was already disabled in cURL.
In config.h we had a:
#if OPENSSL_VERSION_NUMBER >= 0x10100000L
#define UNREALIRCD_DEFAULT_ECDH_CURVES "X25519:secp521r1:secp384r1:prime256v1"
#else
#define UNREALIRCD_DEFAULT_ECDH_CURVES "secp521r1:secp384r1:prime256v1"
#endif
...which is fine in theory, but openssl headers are not included at that point,
so OPENSSL_VERSION_NUMBER was not defined.
From now on, we have:
#define UNREALIRCD_DEFAULT_ECDH_CURVES_PRIMARY "X25519:secp521r1:secp384r1:prime256v1"
#define UNREALIRCD_DEFAULT_ECDH_CURVES_SECONDARY "secp521r1:secp384r1:prime256v1"
...and we try them in that order. If both fail, we exit with an error (like before).
This because X25519 is not available in OpenSSL before 1.1.0 (so really old)
and may also not be available when running in FIPS mode.
In all my tests on real servers this was never a reported leak,
because the dbuf_delete() already happens at other places where the
client is marked dead.
However, with my (private) fuzzing patches I need this freeing because
of a slightly different code path.
I'm putting the patch in mainline just in case I'm wrong and it does
trigger in some kind of niche situation.
The IRCd is still responsive (as the bad I/O is not prioritzed) but this
isn't good either. Only happens with some rare triggers.
This was previously reported over e-mail in an older UnrealIRCd version
but after 6-8 hours of debugging I was never able to trigger it.
Later it finally happened on one of my servers and I could debug it.
Reported by bss on IRC.
Changed:
r->ipv6 = IsIPV6(client);
To:
r->ipv6 = IsIPV6(client) ? 1 : 0;
The problem is that:
#define IsIPV6(x) ((x)->flags & CLIENT_FLAG_IPV6)
(..so without ?1:0..)
made this effectively:
r->ipv6 = CLIENT_FLAG_IPV6;
..which is..
#define CLIENT_FLAG_IPV6 0x800000000 /**< client is using IPv6 */
.. and 0x800000000 doesn't fit in r->ipv6, which is of size 'char' (so max is 0xff)
+#define HAS_ASN1_TIME_diff
+#define HAS_SSL_CTX_SET_MIN_PROTO_VERSION
+#define HAS_SSL_CTX_SET_SECURITY_LEVEL
+#define HAS_X509_check_host
+#define HAS_X509_get0_notAfter
In practice, this only adds that we now do certificate expiry checks
and give warnings, like on *NIX.
The HAS_X509_check_host is good because then OpenSSL/LibreSSL code is
used instead of the one we have from cURL and the ssl conservatory.
To be honest I wanted to rip out this fallback completely at first,
but let's do that in next major version of UnrealIRCd and not during
an existing series.
The HAS_SSL_CTX_SET_* would have given an admin the option to downgrade
to TLSv1.0 or TLSv1.1 but LibreSSL no longer builds with these since
LibreSSL 3.8.1, which is sensible, so... no actual change there.
I'll document the behavior in the docs (wiki), though.
Also the previous claim in b653c68df0 with
regards to what curves were actually enabled in our LibreSSL UnrealIRCd 6
builds was incorrect, an hour ago I claimed X448 would show up as an extra,
but that is not the case (that was with OpenSSL). The correct statement is:
"This also meant the default curves that were offered were up to LibreSSL,
which meant the following list in practice:
Elliptic curves offered: prime256v1 secp384r1 X25519
Instead of:
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519"
So it was only missing secp521r1. Nothing major.
"[error] ecdh-curves specified but your OpenSSL/LibreSSL library does not
support setting curves manually by name. Either upgrade to a newer library
version or remove the 'ecdh-curves' directive from your configuration file"
This also meant the default curves that were offered were up to LibreSSL,
which meant the following list in practice:
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
Instead of:
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519
Not that X448 is considered bad, it just didn't match what we claimed in
the docs at https://www.unrealircd.org/docs/TLS_Ciphers_and_protocols
Fixed by: #define HAS_SSL_CTX_SET1_CURVES_LIST
Now this works like:
if the time param exists, even without a reason, it will be checked if it's a time param. if it's not a time param, it'll be considered to be the reason (or the first part of it anyway)
Reported by PeGaSuS in https://bugs.unrealircd.org/view.php?id=6105
... and make set::max-inherit-extended-bans::ban-exception default to 0
because that functionality is not implemented
The +e's are already checked when using +b ~inherit though..
lookup fails the old result stays there which is confusing.
Reported on IRC where 10.x.x.x was shown as "Poland" which was a
leftover from the "real IP" before WEBIRC spoofing was used to set
the IP to 10.x.x.x. Reported by Jellis.
* [Security group blocks](https://www.unrealircd.org/docs/Security-group_block)
are now hidden in lists by default. If you want the security group to be shown
in things like `MODE #channel +b ~security-group:x` (which shows a list)
then you need to use `public yes;`. The default security groups
like known-users, webirc-users, etc. are public by default.
Bram Matthys