[MDEV-25799] tls_version=TLSv1.3 does not work with WolfSSL based server builds Created: 2021-05-27  Updated: 2021-07-21  Resolved: 2021-07-21

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

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-22221 Official binary compiled with WolfSSL... Closed
Relates
relates to MDEV-25701 Two-way TLS does not work with WolfSS... Confirmed

 Description   

I've set up two machines, one named "openssl" with MariaDB installed from our own Ubuntu package repository, so built against OpenSSL, and one named "wolfssl" with MariaDB installed from our generic Linux binary tarball, so built against WolfSSL

Both servers are set up for SSL/TLS, and are configured to enforce TLSv1.3 with

tls_version=TLSv1.3

The mysql command line client is able to connect to the OpenSSL based MariaDB server using encryption from both machines just fine.

Neither client can connect to the WolfSSL based server though.

The client using OpenSSL reports:

vagrant@openssl:~$ mysql -u x509 -psecret -h wolfssl --ssl
ERROR 2026 (HY000): SSL connection error: wrong version number

And the WolfSSL based client basically reports the same, just with different wording:

vagrant@wolfssl:~$ mysql -u x509 -psecret -h wolfssl --ssl
ERROR 2026 (HY000): SSL connection error: A packet with illegal or unsupported version was received.

When removing the

tls_version=TLSv1.3

line from the configuration file, and restarting the MariaDB server using WolfSSL, encrypted connections are possible, but only use TLSv1.2

When connecting from the WolfSSL based client to the OpenSSL based server, both agree on using TSLv1.3 as the highest mutually supported version though.



 Comments   
Comment by Vladislav Vaintroub [ 2021-07-21 ]

There is no WolfSSL-based client. C/C does not support building WolfSSL-based clients, allegedly because of the licensing issues.

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