I'm wondering why at SSL_CTX_new, and not when the library is loaded? Do you think there is an advantage to do it at that time? Like that daemons create a new SSL_CTX_new() on SIGHUP?

The file is actually loaded on OPENSSL_init_ssl() so the commit message is not correct, I'll modify it. However it would actually be nice if it was possible to re-load the file on SSL_CTX_new() otherwise it would require restart of all daemons to apply the changed system policy. I wonder if there is a possibility to reload the configuration file without unwanted side-effects.

I've opened issue #5041 documenting what this merge request addresses.

Test and documentation added. Can you please still consider this for 1.1.1?

Sigh. Nobody else on the team seems to care much about this, unfortunately. I care a lot but I am only one person. Ping @openssl/committers

One risk is that this can introduce security issues in Postfix by unexpectedly enabling trust in the default CAs (CAfile and CApath) in the SMTP server, which till now would by default trust only specific CAs (perhaps just a local one) and possibly allow relaying of email from all clients that have a client from such a CA.

If the trust is expanded behind Postfix's back to include all the WebPKI CAs, the system becomes an open relay.

There may other costs and downside to untroducing this as a new behaviour of SSL_CTX_new(). It might make more sense to encourage applications that want this type of system-wide configuration to use a new function that has the desired behaviour. SSL_CTX_new_default() or similar.

What about just filtering out / ignoring the certificate related options from the system-default?

I mean by adding a new API and requiring applications to switch to it, we can dump this altogether as this is not going to be "system default" but "some changed applications default".

Although I know that even the current patch is not ideal in this regard either because it requires the application to initialize the OpenSSL with OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG) otherwise the configuration file is not loaded. But at least patching OpenSSL initialization in applications should be much more easily achievable than patching all calls to SSL_CTX_new().

Id support the general idea of providing a system-wide configuration for libssl and libcrypto. For example it should be possible to enable platform specific hardware support via engine on system level rather than requiring applications to be aware of the hw they are running on. The same applies to entropy source configuration, see my comment in #4394 .

This is not directly related to this specific PR, but there are multiple PRs/issues regarding configuration file and discussion seems to take place here ..

I am glad to finally see some discussion on this. I think the expectation is that this would be used to increase the default level of security for all applications. But Viktor raises a good point about things like changing the default trust store affecting some applications in the wrong way. I think those applications are in the minority however.

Perhaps instead of having an "opt-in" we have an "opt-out" and applications like postfix would use it.

Either opt-out or a new API entry point (opt-in) is I think required. I'm also concerned about the performance impact of whatever processing this might imply. SSL_CTX_new() is called not only when the application first initializes, but IIRC also when creating contexts for SNI, and this should involve excessive processing that can be avoided, or unwanted processing that might bring in unexpected settings.

My general view is that OpenSSL provides low-level primitives that can be composed to yield higher-level user-friendly functions. This makes it possible to make various choices, without being forced into a one-size fits all model. The downside is that we've not always (or often not) provided the higher-level user-friendly interfaces. So we should do more of that, but not necessarily by converting the low-level functions to one-size fits all common-case interfaces.

Thoughts?

Either opt-in or opt-out, this feature better be visible/displayed when calling a kind of openssl version -a' command.

If I may attempt to summarize the discussion above, is it true we have consensus for the following requirements for such a change:

• Ability to modify shipped default settings from a configuration file on run-time, system-wide
• That configuration file should be the default openssl config file
• Administrators/users should be able to modify those defaults
• Applications must have the option to opt-out from system-wide defaults

Is that correct?

My understanding is that @paulidale @richsalz and @kroeckx are ok with that summary (please correct me if I'm wrong). @vdukhovni is that summary ok with you? Do you have any suggestion for the opt-out mechanism? Is calling OPENSSL_init_ssl() without the OPENSSL_INIT_LOAD_CONFIG flag ok or something else should be introduced?

I can't see why an application should not be able to create a blank context.

The above summary does not explicitly take into account a transition plan from the current state to the "new" state of affairs.

And it does not reflect @vdukhovni's concern about the timing performance impact either.

This PR changes the behaviour of SSL_CTX_new with no way to access the original behaviour.
Why can't we not get the original function, maybe as SSL_CTX_new_unconfigured ?
Additionally to opt-out at initialization time?

Whatever we do, "looking at the application name" is not a robust mechanism we should consider.

Please note that no config files will be read on SSL_CTX_new with the patch. Just the configuration from the file read on initialization is applied to the SSL_CTX. I do not really think performance would be an issue for large majority of OpenSSL using apps.

OK, so what about this proposal:
Add SSL_CTX_new_ex() with additional parameter flags which would allow to initialize the SSL_CTX with or without applying the system default settings.
As for whether SSL_CTX_new() should call the SSL_CTX_new_ex() with the flag to apply the system default or not to apply to them, we could leave it to later discussion.

If the #2397 lands first it should already add the flags parameter so we do not have to create additional API call.

@vdukhovni the distros already handle default CA stores somehow. Here the major driver is a crypto policy support in regards to enabled algorithms and minimum key size limits.

@richsalz, you removed the "Post 1.1.1" milestone... what milestone would you like to see?

I want this in 1.1.1 I want us to make it easy for admins and downstream distro maintainers to change defaults, even if a postfix maintainer doesn't like it.

Ok, so 1.1.1 milestone it is

I'm less concerned about change-on-the-fly approaches - i.e. just having a one-time load of the configuration file at startup and applying that would meet my expectations. Checking the configuration file and reloading it for every call to SSL_CTX_new isn't what I would expect - and if that was done it should be on a timestamp check caching basis at least. And be able to be overridden - which I guess argues for that being a configuration option - loaded at startup - should we be checking for configuration changes for each SSL_CTX_new call - as a suggestion for how to handle it.

And I also think this should be going into the 1.1.1 release as well ...

I think the simplest thing to understand is read the file at startup, don't check for run-time changes.

@richsalz Which is what actually happens with the current patch. So do I understand it correctly that the only missing thing (if vote passes) is adding the opt-out interface? I'd say it should also accommodate the #3761 to avoid proliferation of new API calls.

Yes, that's my opinion. There is some discussion going on in openssl-project mailing list.

Merged. Please see #5671 for some remaining issues.