Tested on:
Windows 10 1809 17763.1131 Official 10.4.12 MSI installer
Fedora 31 in Docker on Debian 10 Linux 4.19.0 Official 10.4.12 Binary tarball
(wolfSSL Version 4.3.0)

btw nice use of openssl s_client, I hadn't realised they had added --starttls mysql

PR complete.

WolfSSL TLSv1.3 when a client provides a certificates will segfault until https://github.com/wolfSSL/wolfssl/pull/2901 is applied. As a test of this. run main.ssl_8k_key test with --tls-version=TLSv1.3.

There are TLSv1.3 test gaps however I've added mysqltest support to TLS-VERSION in the PR.

FP_MAX_BITS is twice the HAVE_FFDHE_3072 and clang/x86_64 gets the higher numbers enabled so compiles and tests pass on gcc/x86_64 and clang(8)/x86_64 (Linux only tested). Bohan's test cases above also pass correctly.

danblack, is PR really complete?

I'm trying to use the TLSv1.3 that supposedly would work, with WolfSSL

C:\work\10.4\xxx\mysql-test>perl mysql-test-run.pl openssl_1 --mysqld=--tls-version=TLSv1.3

<skip>

CURRENT_TEST: main.openssl_1

mysqltest: At line 27: query 'connect  con1,localhost,ssl_user1,,,,,SSL' failed: 2026: SSL connection error: . The message received was unexpected or badly formatted. Error 0x80090326(SEC_E_ILLEGAL_MESSAGE)

The result from queries just before the failure was:

set local sql_mode="";

set global sql_mode="";

drop table if exists t1;

create table t1(f1 int);

insert into t1 values (5);

grant select on test.* to ssl_user1@localhost require SSL;

grant select on test.* to ssl_user3@localhost require SUBJECT "/C=FI/ST=Helsinki/L=Helsinki/O=MariaDB/CN=client";

grant select on test.* to ssl_user4@localhost require SUBJECT "/C=FI/ST=Helsinki/L=Helsinki/O=MariaDB/CN=client" ISSUER "/CN=cacert/C=FI/ST=Helsinki/L=Helsinki/O=MariaDB";

grant select on test.* to ssl_user5@localhost require SUBJECT "xxx";

flush privileges;

build-mariadb-server-10.4]$ perl mysql-test/mysql-test-run.pl openssl_1 --mysqld=--tls-version=TLSv1.3

Logging: /home/dan/repos/mariadb-server-10.4/mysql-test/mysql-test-run.pl  openssl_1 --mysqld=--tls-version=TLSv1.3

vardir: /home/dan/repos/build-mariadb-server-10.4/mysql-test/var

Checking leftover processes...

Removing old var directory...

 - WARNING: Using the 'mysql-test/var' symlink

Creating var directory '/home/dan/repos/build-mariadb-server-10.4/mysql-test/var'...

Checking supported features...

MariaDB Version 10.4.13-MariaDB

 - SSL connections supported

 - binaries built with wsrep patch

Collecting tests...

Installing system database...

==============================================================================

TEST                                      RESULT   TIME (ms) or COMMENT

--------------------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019

main.openssl_1                           [ pass ]    469

--------------------------------------------------------------------------

The servers were restarted 0 times

Spent 0.469 of 6 seconds executing testcases

Completed: All 1 tests were successful.

So definitely need the more tls1.3 tests in the suite. along with the failing 8k test (currently generating a duplicate free, waiting on wolfssl upstream for some clue as to why).

Alright, on Windows the schannel-based client does not do TLSv1.3
Windows 10 has some kind of experimental support, but enabling TLSv1.3v ia registry, plus removing the restrictions on protocols C/C, does not help much . Looks like we have to wait for official support of that, on Windows.

On the non-windows server side, the openssl build has TLSv1.3 now. So should we aim to deliver that with wolfssl while disabling the TLSv1.3 on Windows?

Wolfssl TLSv1.3 8k client certificate support just got fixed upstream (https://github.com/wolfSSL/wolfssl/pull/2933).

So options:

• Wait for next major release 4.5.0 in a couple of months (currently wolfssl submodule is on 4.3.0 and very upstream recently released 4.4.0)
• Update submodule to the commit 390f066 (13 commits after 4.4.0 release https://github.com/wolfSSL/wolfssl/compare/v4.4.0-stable...390f066)

I looked for a hook that could detect a 8k client certificate however CallbackRsaVerify was called too late.

Which mariadb release branch should be targeted for these changes?

Do all openssl builds support TLSv1.3?

Usually, we take major releases. If there is something truly important, I guess an exception is possible.

The submodule changes go into lowest applicable version, which would be 10.4

note: openssl-1.1.1 introduced tlsv1.3 - https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ (and https://github.com/openssl/openssl/blob/master/CHANGES.md#changes-between-110i-and-111-11-sep-2018).

Side note: Downstream in Debian the release team finally gave us premission to use OpenSSL and thus WolfSSL (ssl=bundled) was now dropped for MariaDB 10.5 in Debian and OpenSSL introduced, and along with it support for TLSv1.3. Ref: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ca2574aa88434d1c49456c677b7dcb904902daaf

I allowed AES-GCM on WolfSSL now, but TLS1.3 will have to wait longer.
this is because the last version we currently use (4.6.0) has high severity vulnerability in TLSv1.3 support (CVE-2021-3336) , and 4.7 was not compilable , when we tried to use it.