Upgrade openssl 1.1.1y

Yeah like @buik mentioned OpenSSL 1.1.1 is end of life with last public free release being OpenSSL 1.1.1w. OpenSSL 1.1.1y is only available for those paying extended premium support with OpenSSL.

Yup https://community.centminmod.com/th...by-default-for-el8-el9-in-130-00beta01.25407/ OPENSSL_SYSTEM_USE='y' tells Centmin Mod to build Nginx with EL8 system OpenSSL 1.1.1k which has backported patches but stays on 1.1.1 version number and EL9 system OpenSSL 3.0.7 which has backported patches but stays on 3.0.7 version number.

Yes if Tenable is only detecting 1.1.1 then it will flag either Centmin Mod Nginx OpenSSL 1.1.1 at /opt/openssl/bin/openssl or system EL8's /usr/bin/openssl binaries. For the EL8's /usr/bin/openssl 1.1.1 it will be a false positive as backported fixes are in it. It's only Centmin Mod Nginx OpenSSL 1.1.1w at /opt/openssl/bin/openssl that doesn't get any more updates due to EOL. Hence, why EL8/EL9 Centmin Mod builds now default to OPENSSL_SYSTEM_USE='y' enabled to workaround this.

But if Tenable is purely going by 1.1.1 match and disregarding YUM/RPM distro system backported patches, then that to me is a false positive as it will always complain about EL8's system OpenSSL 1.1.1k version. Or are you saying Tenable is only complaining about Centmin Mod OpenSSL 1.1.1w at /opt/openssl/bin/openssl and not complaining about EL8's system OpenSSL 1.1.1k at /usr/bin/openssl ? In that case Tenable is detecting the code and not just version numbers.

The alternatives for Centmin Mod Nginx crypto library side at least without enabling OPENSSL_SYSTEM_USE='y', is to switch from OpenSSL 1.1.1 to OpenSSL 3.0, 3.1, 3.2, 3.3 and suffer lower performance compared to OpenSSL 1.1.1 (haproxy folks benchmarked OpenSSL 3.0 at 1/10th OpenSSL 1.1.1 performance and OpenSSL 3.1/3.2 at 1/4th of OpenSSL 1.1.1 performance though I haven't seen that for Nginx but it is lower).

Or switch to BoringSSL and loose dual RSA+ECDSA SSL certificate support and loose OCSP stapling. Or switch to Amazon's AWS-LC which is my leading contender for OpenSSL 1.1.1 alternative as it mixes BoringSSL's HTTP/3 QUIC with OpenSSL 1.1.1 base for best performance and will get security updates https://community.centminmod.com/th...crypto-library-support-in-130-00beta01.25415/. But AWS-LC dual RSA+ECDSA SSL certificate support isn't working properly though they list they support it. AWS-LC OCSP stapling they list support but haven't tested yet.

 

@Matt curious if on Centmin Mod 130.00beta01 based EL8/EL9 system you set AWS_LC_SWITCH='y' in persistent config file /etc/centminmod/custom_config.inc and run cmupdate + recompile Nginx via centmin.sh menu option 4 and then do Tenable scan does it complain as well ?

 

Are you planning to remove its entire directory for /opt/openssl/bin/openssl like /opt/openssl/? Or just binary?

Depends on how nginx is compiled, check nginx libs to make sure the directory path isn't being used via

Code (Text):

ldd $(which nginx)

Of course it can be removed if you switch nginx crypto libraries like using AWS-LC https://community.centminmod.com/threads/openssl-1-1-1y.25471/#post-100047

 

Is Tenable also complaining that AWS-LC binary is EOL ? AWS-LC is based off a mix of BoringSSL and OpenSSL 1.1.1 that Amazon AWS-LC development team maintains and would have latest security updates for OpenSSL 1.1.1 side i.e. OpenSSL 1.1.1y and beyond I'd imagine. It's binary is bssl at /opt/aws-lc-install/bin/bssl and reports version 1.29.0

Code (Text):

/opt/aws-lc-install/bin/bssl version
1.29.0

and nginx binary's libaries used when AWS-LC is compiled with Centmin Mod Nginx are at /opt/aws-lc-install/lib64. Here can also see optional zstd-nginx-module https://community.centminmod.com/posts/100062/ at /usr/local/nginx-dep/lib/libzstd.so.1

Code (Text):

ldd $(which nginx)
        linux-vdso.so.1 (0x00007fff5fd2a000)
        libzstd.so.1 => /usr/local/nginx-dep/lib/libzstd.so.1 (0x00007f8064900000)
        libcrypto.so => /opt/aws-lc-install/lib64/libcrypto.so (0x00007f80642b7000)
        libssl.so => /opt/aws-lc-install/lib64/libssl.so (0x00007f8064248000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f8064040000)
        libjemalloc.so.2 => /lib64/libjemalloc.so.2 (0x00007f8063ba1000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f806399d000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f806377d000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8063554000)
        libmaxminddb.so.0 => /usr/local/nginx-dep/lib/libmaxminddb.so.0 (0x00007f80648ec000)
        libpcre.so.1 => /usr/local/nginx-dep/lib/libpcre.so.1 (0x00007f80634dd000)
        libGeoIP.so.1 => /lib64/libGeoIP.so.1 (0x00007f80632a0000)
        libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x00007f806309d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8062cc7000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8062932000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f80625b0000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8062398000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8064884000)

FYI, the binaries themselves are not used by any system software and only used for your own manual purposes i.e. diagnostic troubleshooting features that are only supported in those binaries i.e. BoringSSL's bssl for verifying and testing Cloudflare Post-Quantum KEM https://blog.centminmod.com/2023/10...68-key-exchange-support-in-centmin-mod-nginx/ or for openssl-quic and aws-lc-install and boringssl testing HTTP/3 QUIC. The system OpenSSL won't be able to test such newer technologies.

• /opt/aws-lc-install/bin/bssl
• /opt/openssl/bin/openssl
• /opt/openssl-quic/bin/openssl
• /opt/boringssl/bin/bssl

 

The other alternative if you don't mind slower Nginx/OpenSSL is to use OpenSSL 3.0/3.1/3.2 via 4 variables override in persistent config file /etc/centminmod/custom_config.inc and then run cmupdate and then centmin.sh menu option 4 to recompile Nginx with desired OpenSSL version. Of course then you'd need to keep up to date on OpenSSL version releases at openssl.org. I haven't decided on new Centmin Mod Nginx crypto library default as OpenSSL 3.0/3.1/3.2 is much slower than OpenSSL 1.1.1 while BoringSSL and AWS-LC are actually faster than OpenSSL 1.1.1 for ECDSA ciphers at least. Once I decide, I will update 130.00beta01 or newer with the new defaults.

Switch from Centmin Mod Nginx OpenSSL 1.1.1w default to OpenSSL 3.2.1 with Nginx HTTP/3 QUIC switch from quicTLS OpenSSL 1.1.1 to quicTLS OpenSSL 3.1.5

Code (Text):

OPENSSL_SYSTEM_USE='n'
OPENSSL_QUIC_VERSION='openssl-3.1.5+quic'
OPENSSL_VERSION='3.2.1'
OPENSSL_VERSIONFALLBACK='3.2.1'
OPENSSL_VERSION_OLDOVERRIDE='3.2.1'

Switch from Centmin Mod Nginx OpenSSL 1.1.1w default to OpenSSL 3.1.5 with Nginx HTTP/3 QUIC switch from quicTLS OpenSSL 1.1.1 to quicTLS OpenSSL 3.1.5

Code (Text):

OPENSSL_SYSTEM_USE='n'
OPENSSL_QUIC_VERSION='openssl-3.1.5+quic'
OPENSSL_VERSION='3.1.5'
OPENSSL_VERSIONFALLBACK='3.1.5'
OPENSSL_VERSION_OLDOVERRIDE='3.1.5'

Switch from Centmin Mod Nginx OpenSSL 1.1.1w default to OpenSSL 3.0.14 with Nginx HTTP/3 QUIC switch from quicTLS OpenSSL 1.1.1 to quicTLS OpenSSL 3.1.5

Code (Text):

OPENSSL_SYSTEM_USE='n'
OPENSSL_QUIC_VERSION='openssl-3.1.5+quic'
OPENSSL_VERSION='3.0.14'
OPENSSL_VERSIONFALLBACK='3.0.14'
OPENSSL_VERSION_OLDOVERRIDE='3.0.14'

AFAIK, there's no known applicable security issues with OpenSSL 1.1.1w for TLS server i.e. Nginx, all the listed security vulnerabilities that are addressed in OpenSSL 1.1.1y are for non-TLS server usage cases (non web server)

 

Posted this in Centmin Mod News forum for easier reference to current state https://community.centminmod.com/threads/openssl-1-1-1-eol-alternatives.25488/