SSL_OP_NO_COMPRESSION was presumably added in an attempt to prevent
information leakage in a manner similar to recent attacks on HTTPS.
However, assuming that IRC is vulnerable to the same class of attacks is
incorrect: the behavior of the IRC protocol (a single long-running
connection) is not the same as that of HTTPS (multiple ephemeral
connections). HTTPS's use of ephemeral connections means that certain
assumptions can be made about the contents of the compression
algorithm's dictionaries and the content exchanged between the client
and server (e.g. the content being nearly the same for each connection),
which is not true for IRC. Additionally, they rely on the attacker being
able to coerce the client into creating many HTTPS connections (and
resending some secret token belonging to the user, along with
attacker-controlled data) each time, none of which is possible with IRC.
Lastly, since compression is no longer performed, this option will
result in leaking the lengths of messages transmitted to and from the
client. This option does reduce CPU utilization on Charybdis servers but
also increases bandwidth consumed.
The C standard does not allow constructing pointers beyond one past the end
of an array. Therefore, if size is an unsigned type (size_t), then
buf + size is never less than buf.
Clang on 32-bit took advantage of the undefined behaviour, causing
segfaults.
Lightly tested.
Note that these are not available in old versions of OpenSSL (like FreeBSD
9.x base OpenSSL), so allow them to be missing.
A side effect may be slightly higher CPU consumption and network traffic.
Without a session id context and if client certificates are used, OpenSSL
fails the handshake if an attempt is made to reuse an old session. Various
clients could not reconnect after a disconnection because of this.
See https://bugzilla.mozilla.org/show_bug.cgi?id=858394#c34 for a bug
report.
rb_crypt() was generating different SHA256 ($5$) hashes than glibc,
making hashes generated with charybdis unusable in ratbox and other
software, and vice versa.
Note that you must have options ACCEPT_FILTER_DATA in your kernel
configuration or load the accf_data kernel module. The functionality is
not in the GENERIC kernel.
This allows for some further hardening against synflooding and connection flooding
where no data is actually sent, as the kernel will simply ignore those connections
(well, as far as the ircd is concerned anyway).
Add two mechanism for avoiding name-collisions in a system-wide
installation of charybdis. The ssld and bandb daemons, intended to be
directly used by ircd and not the user, install into libexec when
--enable-fhs-paths is set. For binaries which are meant to be in PATH
(bindir), such as ircd and viconf, there is now an option
--with-program-prefix=progprefix inspired by automake. If the user
specifies --with-program-prefix=charybdis, the ircd binary is named
charybdisircd when installed.
Add support for saving the pidfile to a rundir and storing the ban
database in localstatedir instead of in sysconfdir. This is, again,
conditional on --enable-fhs-paths.
Fix(?) genssl.sh to always write created SSL key/certificate/dh
parameters to the sysconfdir specified during ./configure. The
previous behavior was to assume that the user ran genssl.sh after
ensuring that his current working directory was either sysconfdir or a
sibling directory of sysconfdir.
ERR_error_string() is just broken, as it returns at most 119 chars
which means error messages are frequently truncated.
Allow for 511 chars using ERR_error_string_n().
This lets a user connect with a client certificate, and
passes the certificate's fingerprint to ircd, which
currently just notices it to the user.
A new ssld->ircd message 'F' is used to pass on the
fingerprint.
This is only for OpenSSL for now, not GNUTLS.
If there is no space in the output buffer to report an
error adding to the kqueue, kevent(2) will abort and
return the error in errno (I was correct that it does
not tell you where it failed). So do not abort the loop
if kevent(2) fails and do not log (expected) EBADF.
(ircd wouldn't read or write anymore to certain clients)
This happens because kqueue.c will often try to add
already closed file descriptors to the kqueue. The kernel
tries to report bad file descriptors in the eventlist; if
the eventlist has no space, processing of the changelist
is silently halted.
The fix:
1. allocate two kqlst things, one for what kqlst currently does
and one as output buffer
this ensures the kevent(2) call in rb_select_kqueue() never
drops updates
2. replace the kevent(2) call in kq_update_events() by a loop
that processes the updates one at a time
that doesn't happen much, and it's the only way to be sure
without also getting events out of the queue we cannot process
at that time
libratbox r25354 (jilles)
