- Implemented changes suggested by Jilles
- Remove some unused parameters in functions
- Remove some unused ssl procs
- 63-bit time_t support in TS deltas
- const char * vs char * cleanup
- struct alignment (void *) casts
- signed vs unsigned fixes
- bad memset() call
- Bad LT_MAIN in libratbox
- char -> unsigned char casts for isdigit/isspace/etc calls
Thanks Jilles!
This is in accordance with RFC 7465
<https://tools.ietf.org/html/rfc7465>
Also correct the key exchange mechanism strings; these should be
prefixed with 'k'.
This fixes a compiler warning. The necessary fields of the struct sigevent
were initialized so there was no problem.
Submitted by: Aaron (via IRC)
Reviewed by: Attila
The last byte of balloc.c's block pointer could be changed from 10 or 13 to
0. On amd64, this is not possible. On i386, this is possible and usually
causes a crash soon.
When receiving bans from a bursting server, if kline_delay is set to 0
(the default), rb_event_addonce will be called to schedule an event for
0 seconds in the future. While this works fine for the fallback
rb_event_run function, the epoll implementation ends up scheduling a
timerfd for the event in the past, which is then never executed.
While fixing this, I also made rb_event_add and rb_event_addonce reject
attempts to add events scheduled for 0 seconds in the future; they're
instead rewritten to run 1 second in the future.
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).
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)
In rare cases, this sharing caused the ircd to skip
part of outgoing traffic, e.g. appearing as "not enough
parameters" errors on the other side.
The purpose of this flag can be fulfilled by the writeofs
in the bufhead.
libratbox r25227
This makes the kernel's state agree with our handler pointer.
SSL may need to suspend selecting for reading to write
something, e.g. with renegotiation.
libratbox r25223
