OpenSSL is perfectly capable of having a single context that is shared
by both client and server sessions alike; one simply needs to call
SSL_set_accept_state (for server) or SSL_set_connect_state (for client)
before attempting handshaking.
If initialising the server context fails, but the client one succeeds,
we will not only leak memory, but the error message reported for
initialising the server context might not make sense, because we
initialise the client context after and that could erase or change the
list of queued errors.
This scenario is considered rare. Nevertheless, we now initialise the
client context after *successfully* initialising the server context.
Commit 5c8da48 introduced a fix for issue #186 by freeing the old SSL_CTX
structure before constructing a new one, which could disconnect existing
clients otherwise.
Unfortunately, the freeing is done first, which means that if setting up
a new structure fails for any reason, there will be no usable structures
left, but they are still referenced.
This fix moves the freeing to the end of the function, using intermediate
new variables in the meantime. This problem was discovered while testing
against OpenSSL 1.1.0 RC6.
LibreSSL does not have the new version macros & functions that OpenSSL
1.1.0 implements. This causes a compile-time failure against LibreSSL.
Further, the runtime function for returning the library version returns
the wrong number (the hardcoded constant number SSLEAY_VERSION_NUMBER
aka OPENSSL_VERSION_NUMBER, instead of LIBRESSL_VERSION_NUMBER).
Add more ifdef soup to remedy the situation.
The code already assumes the presence of fopen(3) and errno, and, by
extension, fclose(3) and strerror(3), so just use those instead of the
BIO wrappers.
Additionally, don't fail to initialise if the DH file does exist but
parsing it fails, as per the pre-existing comment about them being
optional.
openssl:
* Don't manually initialise libssl 1.1.0 -- it does this automatically
* SSL_library_init() should be called first otherwise
* Move SSL_CTX construction to rb_setup_ssl_server()
* Test for all required files (certificate & key) before doing anything
* Free the old CTX before constructing a new one (Fixes#186)
* Properly abort rb_setup_ssl_server() on CTX construction failures
* Support ECDHE on more than one curve on OpenSSL 1.0.2 and above
* Clean up ifdef indentation
* Fix DH parameters memory leak
mbedtls:
* Fix certificate fingerprint generation
* Fix library linking order
* Fix incorrect printf()-esque argument count
* Return digest length for fingerprints instead of 1, consistent
with the other backends
sslproc / ssld:
* Fingerprint methods have no assocated file descriptors
* Send TLS information (cipher, fingerprint) before data
* Use correct header length for fingerprint method
Authored-by: Aaron Jones <aaronmdjones@gmail.com>
Authored-by: William Pitcock <nenolod@dereferenced.org>
Authored-by: Simon Arlott <sa.me.uk>
Nothing in the Charybdis or libratbox code calls rb_get_pseudo_random
and under OpenSSL it uses RAND_pseudo_bytes() which is both dangerous
and removed in OpenSSL version 1.1.0.
When building against current OpenSSL (<= 1.0.2) or old LibreSSL
(< 2.2.2) the server will use TLSv1.0 only when connecting to other
servers.
This patch corrects that.
OpenBSD 5.8 includes LibreSSL 2.2.2, which finally brings the API up to
what they claim it is by implementing the new TLS client and server
method APIs. Therefore, in furtherance of commits a4c8c827 and 1a4e224a
we can build with the new APIs if building against (real) OpenSSL 1.1.0
or LibreSSL 2.2.2.
Reported-by: Juuso Lapinlampi <wub@partyvan.eu>
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.
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'.
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.
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.
