Run OPENSSL_config to load system SSL configuration

[jeremyevans]

This can allow the use of non-default ciphers such as GOST using
Ruby if the system OpenSSL configuration allows them.

Fixes Ruby Bug 9822.

[ioquatix]

@jeremyevans is there any harm in doing this that I should consider before merging?

[jeremyevans]

I don't believe there is harm in doing so. This should only load the relevant section of the standard configuration file (which may have different configuration than the compiled-in defaults). So this should only cause an issue if the standard configuration file contains configuration that the person does not want to load. In that case, they should probably fix their configuration file.

Note that this is not my area of expertise, I haven't done more research than reading the man page.

[ioquatix]

Hmmm:

The OPENSSL_config() function is designed to be a very simple "call it and forget it" function. It is however much better than nothing. Applications which need finer control over their configuration functionality should use the configuration functions such as CONF_modules_load() directly. This function is deprecated and its use should be avoided. Applications should instead call CONF_modules_load() during initialization (that is before starting any threads).

https://www.openssl.org/docs/man1.1.0/man3/OPENSSL_config.html

[ioquatix]

The OPENSSL_no_config() and OPENSSL_config() functions were deprecated in OpenSSL 1.1.0 by OPENSSL_init_crypto().

[ioquatix]

This is not my area either but I guess we are both trying our best to make sense of it.

Does the MAN page I referenced make this PR unnecessary? Do we already do OPENSSL_init_crypto()?

[jeremyevans]

I'm using LibreSSL, and there is no mention of deprecation of the function in the LibreSSL man page. However, OpenSSL_init_crypto is explicitly marked as deprecated in the LibreSSL man page:

    This function is deprecated.  It is never useful for any application
     program to call it explicitly.  The library automatically calls it
     internally with an options argument of 0 whenever needed.  It is safest
     to assume that any function may do so.

     To enable or disable the standard configuration file, instead use
     OPENSSL_config(3) or OPENSSL_no_config(3), respectively.  To load a non-
     standard configuration file, refer to CONF_modules_load_file(3).

Not calling this can break things, such as not supporting ciphers that are supported in the standard configuration file, which I believe is the reason the Ruby bug reporter wanted it added.

[ioquatix]

That is so funny.

[ioquatix]

According to https://stackoverflow.com/questions/54556943/openssl-update-into-newer-version-alternative-for-the-deprecated-openssl-confi we don't need any startup functions :/

[jeremyevans]

OK. I guess I'm fine with closing this then, and we can just tell people to upgrade OpenSSL, or to reopen this issue if they would like us to support older OpenSSL versions.

[ioquatix]

I asked on the OpenSSL mailing list what is the best way to deal with this.

[ioquatix]

Here is the response I got:

Reading that PR it seems your objective is to ensure that the config file is
loaded before you do any libssl work.

How OpenSSL behaves depends on the version. Note that OpenSSL 1.1.0 is now out
of support, and OpenSSL 1.0.2 goes out of support at the end of this year.

From OpenSSL 1.1.0 and onwards OpenSSL auto-initialises so, in most cases, there
is no need to explicitly call initialisation functions such as
OPENSSL_init_crypto() or OPENSSL_init_ssl(). The only reason for applications to
ever call these functions directly is if you want some non-default
initialisation to occur. I notice that Ruby's SSL module is explicitly calling
OPENSSL_init_ssl() with 0 and NULL for arguments - which just gives you the
default initialisation. There seems little point in this - that will happen
automatically the first time you create an SSL_CTX.

From OpenSSL 1.1.1 onwards loading the config file is part of libssl's default
initialisation, i.e. as soon as you create an SSL_CTX OPENSSL_init_ssl() is
called automatically and the config file is loaded. Therefore there is no need
to take any specific action on this version of OpenSSL.

In OpenSSL 1.1.0 (which is now out of support), loading the config file was
not part of the default initialisation. You can force it to be loaded using
the OPENSSL_INIT_LOAD_CONFIG option to OPENSSL_init_ssl():

OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL);

You may choose to do this unconditionally in both 1.1.0 and 1.1.1 if you wish.
In 1.1.1 it has no effect because that's the default anyway - but it does no harm.

OpenSSL 1.0.2 (out of support from the end of this year) does not automatically
initialise/de-initialise and OPENSSL_init_crypto() and OPENSSL_init_ssl() do not
even exist. Therefore you have to call initialisation functions explicitly.
Calling OPENSSL_config() there would seem reasonable.

Hope that helps,

Matt