Enable OpenSSL legacy providers support

[vitalii-kyktov]

Overview

This pull request introduces a modification to the build process to include the legacy module (legacy.so) in the OpenSSL installation. This change is essential for enabling certain legacy ciphering algorithms that might still be required for specific integrations.

Key Changes

• Build Flag Addition: Added the enable-legacy flag in the OpenSSL build process. This flag allows OpenSSL to compile and include legacy cryptographic algorithms.
• Legacy Module Inclusion: The legacy.so file is now copied into the final build. This enables runtime configuration of OpenSSL to use legacy ciphers.
• Use Case: The primary motivation for this change is the need to support the RC4 algorithm, which is still required in some legacy systems and integrations.

Important Notes

• Legacy Algorithms Not Loaded by Default: Legacy algorithms are not enabled by default in the OpenSSL runtime. To load them, you must configure OpenSSL through environment variables:
  1. Set the environment variable OPENSSL_MODULES to point OpenSSL to the location of additional modules:

     OPENSSL_MODULES="/opt/lib/ossl-modules"

  2. Create a custom OpenSSL configuration file with the following content to activate both the default and legacy providers:

     openssl_conf = openssl_init
     
     [openssl_init]
     providers = provider_sect
     
     [provider_sect]
     default = default_sect
     legacy = legacy_sect
     
     [default_sect]
     activate = 1
     
     [legacy_sect]
     activate = 1

  3. Point OpenSSL to use the custom configuration file by setting the OPENSSL_CONF environment variable:

     OPENSSL_CONF="{path to custom openssl config file}"

Impact

By including the legacy module and providing instructions on how to enable legacy algorithms, this change ensures that applications requiring older encryption methods can function correctly without significant changes to their cryptographic dependencies.

[driskell]

Is it worth defining the modules path in the layer so there’s one less step? I think most places referencing enabling the legacy providers document the conf environment but not the module path so it could catch some people out

[GrahamCampbell]

I'm not sure this is a good idea to include for all Bref users. It may be better for you to compile your own image(s).

[driskell]

OpenSSL builds the legacy provider by default so in a way this provider is usually distributed in most operating systems that provide it and is kind of already being built by Bref but is being actively excluded so kind of shipping a non-default setup. (See - https://github.com/openssl/openssl/blob/openssl-3.3.1/INSTALL.md#no-legacy note above says if no-xxx is documented than the default is enable - so the enable-legacy in this PR is unnecessary at the moment.)

I think if the default was to not build legacy then I would agree as then Bref is not actively delivering something weak. But I think as the default it to ship it it probably makes sense. Perhaps it just needs the “enable-legacy” removing so it automatically stops shipping when OpenSSL switches the default as at that point everywhere will have to rebuild their own. Just at moment it’s like everywhere is fine except Bref as it actively does something nothing else does

[driskell]

I think this don’t exist in this one as it OpenSSL 1.1.1w and not 3