because so many people had a broken system/wget/curl, that is: without
the appropriate trusted CA certificates installed. If this is still
the case, then: too bad. People who DO have a proper setup shouldn't
be held back with regards to security by such users.
This so upcoming UnrealIRCd version will work with TLSv1.3 whenever it
becomes an official standard and is included in OpenSSL/LibreSSL.
(Verified to work with openssl git master branch)
to validate the certificate of the link, making sure that:
1) The certificate is issued by a trusted Certificate Authority (CA).
2) The name on the certificate matches the name of the link block.
Some things still need to be done: documentation, more testing, and
using the X509_check_host() function when available.
Nobody used this option and it only caused the following confusing
(and potentially insecure) behavior:
Previously if you had 'verify-certificate' enabled then the certificate
would be checked, BUT if it was a self-signed certificate (and thus
not passing verify-cert) it was STILL allowed unless you also
specified the 'no-self-signed' option. This might be correct as per
documentation but is way too confusing for the user.
Now you simply have to choose whether you verify the certificate or
not. No special handling for self-signed certificates.
connected to a server introducing himself as irc2.test.net. This
was rather confusing, of course. Wasn't much of a security issue since
this only happened in outgoing connects and naturally all authentication
need to pass as well.
This is done for users on shared IRCd shells[*] which may be used to (or
forced to) connect services via their alias IP rather than 127.0.0.1
due to bind restrictions. This, in turn, to ease the transition to
set::plaintext-policy::server deny.
[*] Side-note: The UnrealIRCd team recommends using a VPS and not a
shared shell, as the latter is considerably less secure.
* The 'ban too broad' checking was broken. This permitted glines such
as 192.168.0.0/1 being set. Now it rejects CIDR of /15 and lower.
To disable this safety measure you can (still) use:
set { options { allow-insane-bans; }; };