feature set they support (2.0 even!), deliberately breaking
backward compatibility. Therefore, in order to fix a regression
introduced by commit a4c8c827 with regard to LibreSSL's stupidity,
unconditionally use the old TLS API if building against LibreSSL.
- 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.
