Bug#1032074: libdbd-mysql-perl: SSL connection error: Enforcing SSL encryption is not supported

[root]

Package: libdbd-mysql-perl
Version: 4.050-2
Severity: normal

Dear Maintainer,

I'm running a mailing list implemented in Perl, which draws on a mysql database. It authenticates
to the database using X.509. This setup runs for many years and it did not change any code for
years. The last successful use was February 20th or later.

In the meantime I installed the Debian updates e.g., mariadb and libssl. Apparently, libgnutls
was at least a day before that.

When I now try to connect I receive:

DBI connect('database=MList;mysql_ssl=1;mysql_ssl_client_key=/etc/postfix/mlist.key.pem;mysql_ssl_client_cert=/etc/postfix/mlist.cert.pem;mysql_ssl_ca_file=/etc/certs/cacert.pem;host=mysql.example.com','mlist',...) failed: SSL connection error: Enforcing SSL encryption is not supported at /usr/local/lib/mlist/MListDB.pm line 189.

However, using mysql immediately:

mysql -v -u mlist --ssl-ca /etc/certs/cacert.pem --ssl-cert /etc/postfix/mlist.cert.pem --ssl-key /etc/postfix/mlist.key.pem -h mysql.example.com MList

works as expected i.e., I am logged into MList as mlist. Also, using openssl s_client connects
and negotiates a TLS ticket.

The CN of the mysql server's certificate matches the host of DBI connect. The CN of the client's
certificate matches 'mlist' i.e., then user name.

-- System Information:
Debian Release: 10.13
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-17-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdbd-mysql-perl depends on:
ii libc6 2.28-10+deb10u2
ii libdbi-perl [perl-dbdabi-94] 1.642-1+deb10u2
ii libgnutls30 3.6.7-4+deb10u10
ii libmariadb3 1:10.3.38-0+deb10u1
ii perl 5.28.1-6+deb10u1
ii perl-base [perlapi-5.28.1] 5.28.1-6+deb10u1
ii zlib1g 1:1.2.11.dfsg-1+deb10u2

libdbd-mysql-perl recommends no packages.

libdbd-mysql-perl suggests no packages.

-- no debconf information

[Florian Schlichting]

Hi,

On Mon, Feb 27, 2023 at 01:34:49PM +0100, root wrote:
> In the meantime I installed the Debian updates e.g., mariadb and libssl. Apparently, libgnutls
> was at least a day before that.

have you had a look at the changelog for these updates?

>
> When I now try to connect I receive:
>
> DBI connect('database=MList;mysql_ssl=1;mysql_ssl_client_key=/etc/postfix/mlist.key.pem;mysql_ssl_client_cert=/etc/postfix/mlist.cert.pem;mysql_ssl_ca_file=/etc/certs/cacert.pem;host=mysql.example.com','mlist',...) failed: SSL connection error: Enforcing SSL encryption is not supported at /usr/local/lib/mlist/MListDB.pm line 189.

Looking up your error message in Google ("Enforcing SSL encryption is
not supported") turns up
https://github.com/perl5-dbi/DBD-mysql/issues/333

Do you use the "mysql_ssl_verify_server_cert=1" connection option? Have
you tried setting "mysql_ssl_optional=1"?

HTH, Florian

[Russell King]

Package: libdbd-mysql-perl
Version: 4.050-5+b1
Followup-For: Bug #1032074

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?

Upgrading from Debian Buster to Debian Bookworm.

I have custom perl scripts that run my Linux Kernel patch management
system which make use of DBD::mysql to contact a MariaDB server in
another VM. The MariaDB server is running Debian Buster.

Capturing traffic on port 3306 and examining with wireshark reveals
that when a Debian Buster system is used to connect to the Debian
Buster MariaDB server, it uses TLS v1.3.

However, Debian Bookworm's DBD::mysql uses TLS v1.1, as does
/usr/bin/mysql. This means that if a recent non-buggy TLS version is
required to connect to a Debian Buster mariadb, Debian Bookworm
systems are incompatible due to the lower TLS version that they
support.

I have tried configuring a minimum TLS version in /etc/ssl/openssl.cnf
to increase the security level via:

[openssl_init]
+ssl_conf = ssl_sect

+[ssl_sect]
+system_default = system_default_sect

+[system_default_sect]
+MinProtocol = TLSv1.2
+CipherString = DEFAULT@SECLEVEL=2

but this still results in DBD::mysql using TLS v1.1.

This obviously causes a regression where the mariadb server is set to
a modern minimum non-buggy security level, and thus has *security*
implications given that TLS v1.1 is no longer regarded as secure.

I suspect this is a problem with mariadb shipped with Debian Bookworm
rather than being specific to the perl DBD driver.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 6.1.0+ (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash

Init: systemd (via /run/systemd/system)

Versions of packages libdbd-mysql-perl depends on:

ii libc6 2.36-9
ii libdbi-perl [perl-dbdabi-94] 1.643-4
ii libmariadb3 1:10.11.3-1
ii perl 5.36.0-7
ii perl-base [perlapi-5.36.0] 5.36.0-7

[Russell King]

Some further information:

Despite following the recommended debian upgrades, my /usr/bin/mysql
appears to have been left over from mariadb-client-core-10.1 and thus
was ancient, so we can disregard the packet traces from this. Even more
misleading, both the dbitracing from libdbd-mysql-perl and that version
of mysql both report error 2026 but without much detail, which leads one
to believe they are the same when they very much are not. Specifically, /
usr/bin/mysql discards the reason reported from the SSL library why the
SSL connection failed - and this is a lesson that hiding error messages
by replacing them with something else is bad!

Digging into libdbd-mysql-perl, it turns out this regression is down to
this change in mariadb:

https://github.com/mariadb-corporation/mariadb-connector-c/commit/
a37b7c3965706f9a062baaba0c494dd6efb2c306

Under Bullseye, mysql_get_client_version() reports 100519.
Under Bookworm, mysql_get_client_version() reports 30305.

This number is important. In libdbd-mysql-perl, dbdimp.h has this check:

static inline bool ssl_verify_also_enforce_ssl(void) {
#ifdef MARIADB_BASE_VERSION
my_ulonglong version = mysql_get_client_version();
return ((version >= 50544 && version < 50600) || (version >=
100020 && version < 100100) || version >= 100106);
#else
return false;
#endif
}

Consequently, under Bullseye, this would return true, but under
Bookworm, this now returns false.

This has the effect that libdbd-mysql-perl now refuses any combination of
options that ask it to enforce SSL in mysql_dr_connect():

if (ssl_enforce) {
...
#elif defined(HAVE_SSL_VERIFY)
if (!ssl_verify_also_enforce_ssl()) {
set_ssl_error(sock, "Enforcing SSL encryption is not
supported");
return NULL;
}

So, any combination of options (such as merely setting "mysql_ssl=1")
results in this error message.

This is a regression in libdbd-mysql-perl caused by the above referenced
commit in mariadb's client library which changes the return value of
mysql_get_client_version() to return the _package_ version, and thus a
very much smaller number than libdbd-mysql-perl expects.

[Russell King]

It seems mariadb developers know about the issue:

https://github.com/mariadb-corporation/mariadb-connector-c/pull/219