solanum-vs-hackint-and-char.../librb
Aaron Jones a90f22c92d OpenSSL: Support configuration of TLSv1.3 ciphersuites
The OpenSSL developers decided, during the OpenSSL 1.1.1 development
phase, to use a different API and different set of lists for TLSv1.3
ciphersuites, than for every TLS version preceeding it.

This is stupid, but we have to work with it.

This commit also improves configuration fault resilience. The reason
is that if you don't pass any valid old-style ciphersuites, OpenSSL
will not negotiate an older protocol at all. However, when they
implemented the new API, they decided that lack of any valid
ciphersuites should result in using the defaults. This means that if
you pass a completely invalid ciphersuite list (like "foo"), OR if
you pass a TLSv1.2-only ciphersuite list, TLSv1.3 continues to work.
This is not mirrored; passing a TLSv1.3-only ciphersuite list will
break TLSv1.2 and below.

Therefore we work around this lack of mirroring by falling back to
the default list for each protocol. This means that if
ssl_cipher_list is complete garbage, the default will be used, and
TLS setup will succeed for both protocols. This is logged, so that
administrators can fix their configuration.

I prefer this approach over explicitly disabling the protocols if
their respective ciphersuite lists are invalid, because it will
result in unusable TLSv1.3 if people run newer solanum with their
older charybdis/solanum configuration files that contain custom
ssl_cipher_list definitions. Hindering TLSv1.3 adoption is not an
option, in my opinion.

The downside of this is that it is no longer possible to disable a
protocol family by not including any of its ciphersuites. This could
be remedied by an ssl_protocol_list configuration directive if it is
decided that this functionality is ultimately necessary.

This work is not required for either of the other TLS backends,
because neither of those libraries yet support TLSv1.3, and in the
event that they eventually do, I expect them to allow configuration
of newer ciphersuites with the existing APIs. This can be revisited
if it turns out not to be the case.

Signed-off-by: Aaron Jones <me@aaronmdjones.net>
Tested-by: Aaron Jones <me@aaronmdjones.net>
2021-02-07 11:52:58 +00:00
..
include librb: add rb_{set,clear}_cloexec 2021-01-26 00:03:48 -05:00
src OpenSSL: Support configuration of TLSv1.3 ciphersuites 2021-02-07 11:52:58 +00:00
acinclude.m4 Remove the rest of the SVN id tags 2016-03-23 20:13:12 -04:00
autogen.sh *sigh* comment these out until travis is fixed. 2016-04-10 17:12:42 -05:00
configure.ac Innovation by sed 2020-10-15 15:52:41 +01:00
COPYING rename libratbox to librb, since its pretty modified anyway 2016-03-06 02:30:20 -06:00
CREDITS Innovation by sed 2020-10-15 15:52:41 +01:00
install-sh Add these for now until travis actually gets their shit together. 2016-04-10 17:07:33 -05:00
librb.pc.in Innovation by sed 2020-10-15 15:52:41 +01:00
Makefile.am Properly clean up build artifacts. 2016-04-09 04:55:57 -05:00
README.md update librb README to explain the namechange 2016-03-06 02:33:48 -06:00
TODO rename libratbox to librb, since its pretty modified anyway 2016-03-06 02:30:20 -06:00

librb

This is based on libratbox, the common runtime support code in ircd-ratbox. It has significant modifications and is no longer compatible with libratbox itself (nor can be used as a dropin replacement), so we renamed it.

original libratbox notes

  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.