[MDEV-15848] version_ssl_library seems to be incorrect in some cases Created: 2018-04-11  Updated: 2020-08-25  Resolved: 2018-06-19

Status: Closed
Project: MariaDB Server
Component/s: SSL
Affects Version/s: 10.2.12, 10.1.31
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: ssl, variable

Issue Links:
Relates
relates to MDEV-18277 Client can't validate server certific... Closed

 Description   

The version_ssl_library variable seems to be incorrect in some cases.

For example, my RHEL 7 instance has the following OpenSSL version:

$ cat /etc/redhat-release
 
Red Hat Enterprise Linux Server release 7.2 (Maipo)
 
$ rpm -qa | grep openssl
 
openssl-libs-1.0.2k-12.el7.x86_64
 
openssl-1.0.2k-12.el7.x86_64

But version_ssl_library seems to refer to an older version:

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
 
+---------------------+---------------------------------+
 
| Variable_name       | Value                           |
 
+---------------------+---------------------------------+
 
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
 
+---------------------+---------------------------------+
 
1 row in set (0.00 sec)

I did restart mysqld to ensure that it is not using an old version of OpenSSL that has been upgraded.

 Comments   
Comment by Sergei Golubchik [ 2018-05-06 ]

How can I repeat that? What steps do I need to do to get to this output?

Comment by Geoff Montee (Inactive) [ 2018-05-07 ]

To reproduce this, all I did was:

1.) Start up an RHEL 7 VM.

2.) Install the latest version of OpenSSL for that distribution, which is openssl-1.0.2k-12.el7.x86_64.

3.) Start up MariaDB.

4.) Execute the following:

SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';

That showed "OpenSSL 1.0.1e-fips 11 Feb 2013" as the version, even though openssl-1.0.2k-12.el7.x86_64 is installed.

I'm not actually sure if this is a MariaDB issue or an OpenSSL issue. I searched for a similar string in the OpenSSL shared library, but didn't find this exact string:

$ ldd $(which mysqld) | grep ssl
 
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f1fe8ff3000)
 
$ strings /lib64/libssl.so.10 | grep "OpenSSL 1.0"  
SSLv3 part of OpenSSL 1.0.2k-fips  26 Jan 2017
 
TLSv1 part of OpenSSL 1.0.2k-fips  26 Jan 2017
 
DTLSv1 part of OpenSSL 1.0.2k-fips  26 Jan 2017
 
OpenSSL 1.0.2k-fips  26 Jan 2017
 
$ mysql -u root --execute="SHOW GLOBAL VARIABLES LIKE 'version_ssl_library'"
 
+---------------------+---------------------------------+
 
| Variable_name       | Value                           |
 
+---------------------+---------------------------------+
 
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
 
+---------------------+---------------------------------+

Comment by Sergei Golubchik [ 2018-06-19 ]

I don't see what we can do here, it's how OpenSSL works.

Symbols in libssl.so are versioned, and mysqld gets linked with the symbols of the currently installed version:

$ nm sql/mysqld|grep SSLeay_version
 
                 U SSLeay_version@@OPENSSL_1.0.1

When you install 1.0.2, it has symbols both with the new and old versions, that's how shared libraries provide backward compatible functionality:

$ readelf -a /lib64/libcrypto.so.10|grep SSLeay_version
 
  1375: 000000000006f5d0    21 FUNC    GLOBAL DEFAULT   12 SSLeay_version@libcrypto.so.10
 
  1376: 000000000006f5f0    21 FUNC    GLOBAL DEFAULT   12 SSLeay_version@OPENSSL_1.0.1
 
  1378: 000000000006f580    70 FUNC    GLOBAL DEFAULT   12 SSLeay_version@@OPENSSL_1.0.2

So, mysqld will be using SSLeay_version@OPENSSL_1.0.1 and it's no surprise that it will report the version as "1.0.1".

In other words, if MariaDB was compiled with OpenSSL 1.0.1, after you install OpenSSL 1.0.2 it will not be using 1.0.2, it will be using 1.0.2-pretending-to-be-1.0.1

Generated at Thu Feb 08 08:24:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.