784ce5c1cc
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. |
||
---|---|---|
.. | ||
include | ||
src | ||
.indent.pro | ||
acinclude.m4 | ||
aclocal.m4 | ||
ChangeLog | ||
config.guess | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
CREDITS | ||
depcomp | ||
INSTALL | ||
install-sh | ||
libratbox.pc.in | ||
ltmain.sh | ||
Makefile.am | ||
Makefile.in | ||
missing | ||
README | ||
TODO |
This is libircd from ircd-ratbox. A few notes about this library: 1. Most of this code isn't anywhere near threadsafe at this point. Don't hold your breath on this either. 2. The linebuf code is designed to deal with pretty much 512 bytes per line and that is it. Anything beyond that length unless in raw mode, gets discard. For some non-irc purposes, this can be a problem, but for ircd stuff its fine. 3. The helper code when transmitting data between helpers, the same 512 byte limit applies there as we recycle the linebuf code for this.