At the moment, if a link quits in just the right (wrong [1]) way,
the quit reason will resemble:
<-- foo (~bar@baz) has quit (Read error: (-0x0) )
This should resolve that.
[1] Peers should send a close_notify alert before abruptly shutting
down their socket. This will result in a sane quit message:
<-- foo (~bar@baz) has quit (Read error: (-0x7880) SSL -
The peer notified us that the connection is going to be closed)
[ci skip]
This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
apply this fix if you support SASL on your servers, or unload m_sasl.so
in the meantime.
As a client, require all peers (i.e. other IRC servers) to support secure
renegotiation. Break handshakes with servers that don't. We do not
renegotiate our sessions, but this is the most secure option regardless.
As a client, disable TLS Session Tickets. The server side MbedTLS code
does not have any ticket callbacks configured, so an MbedTLS IRC Server
will not issue tickets -- however, others could. Server connections are
not expected to be short-lived enough to benefit from the usage of tickets,
and their issuance harms forward secrecy.
I have removed all non-MbedTLS-specific code from this backend and
copied the non-OpenSSL-specific portions of the OpenSSL backend code
over; as it seems to be more reliable.
If initialising the server context fails, but the client one succeeds,
we will not only leak memory, but the error message reported for
initialising the server context might not make sense, because we
initialise the client context after and that could erase or change the
list of queued errors.
This scenario is considered rare. Nevertheless, we now initialise the
client context after *successfully* initialising the server context.
On FreeBSD 4.8, fork(2) doesn't actually behave like fork(2).
Namely, kqueue(2) descriptors are not inherited by the child.
IOW, we can't fork(2) after we get the kqueue(2) descriptor.
So we'll just have to rely on people to actually read the
server log file if they want to understand why their server
is dying during startup.
This moves daemonisation to the end of initialisation which
vastly simplifies the reporting logic and eliminates the need
for the child to communicate to the parent.
This is a backport from the release/4 branch.
Using /dev/random for salt generation is pointless -- it can block, and
any extra randomness it would provide (which is debatable) is not needed,
as salts only need to be unique, not unpredictable.
Commit 5c8da48 introduced a fix for issue #186 by freeing the old SSL_CTX
structure before constructing a new one, which could disconnect existing
clients otherwise.
Unfortunately, the freeing is done first, which means that if setting up
a new structure fails for any reason, there will be no usable structures
left, but they are still referenced.
This fix moves the freeing to the end of the function, using intermediate
new variables in the meantime. This problem was discovered while testing
against OpenSSL 1.1.0 RC6.
LibreSSL does not have the new version macros & functions that OpenSSL
1.1.0 implements. This causes a compile-time failure against LibreSSL.
Further, the runtime function for returning the library version returns
the wrong number (the hardcoded constant number SSLEAY_VERSION_NUMBER
aka OPENSSL_VERSION_NUMBER, instead of LIBRESSL_VERSION_NUMBER).
Add more ifdef soup to remedy the situation.
The code already assumes the presence of fopen(3) and errno, and, by
extension, fclose(3) and strerror(3), so just use those instead of the
BIO wrappers.
Additionally, don't fail to initialise if the DH file does exist but
parsing it fails, as per the pre-existing comment about them being
optional.
