Page MenuHomeMiraheze

Reconfigure TLS settings inside MariaDB
Open, LowPublic


There seem to be various TLS settings inside MariaDB configuration right now, but it's depending on the wildcard cert (should have a new keypair instead) and no ciphers have been configured yet.

OpenSSL has a preference over yaSSL, although it looks like we're already using the MariaDB version with OpenSSL support compiled, so that's great. The goal of this task is not to require TLS connections yet, just to make it working properly so we can concentrate on the clients afterwards.

Event Timeline

Paladox triaged this task as High priority.Jan 16 2019, 20:09
Southparkfan lowered the priority of this task from High to Normal.Feb 9 2019, 01:41

We're definitely using OpenSSL for MariaDB 10.2.24, great. First step would be creating a Miraheze CA with easy-rsa.

Ideally we only use TLS 1.3 or later, but the tls_version variable is only available in the 10.4, which is the development version: see also here. Oh well, at least SSLv3 is disabled..

Ciphers? recommends EECDH+AESGCM:EDH+AESGCM, though a performance comparison is crucial.

Localhost MariaDB (10.4.x) connection (on db6) uses the TLS_AES_256_GCM_SHA384 cipher in conjunction with TLS 1.3, MediaWiki uses the ECDHE-RSA-AES128-GCM-SHA256 cipher in conjunction with TLS 1.2. Per, the configuration on db6 is modern, MediaWiki's settings are considered legacy.

It is noteworthy that AES-NI is lacking on the KVM guests (cloud[12]), which means openssl's speeds on guests are nowhere near as good as on the host: see Can be fixed by directly using the host's CPU, not sure what the disadvantages of that can be. Fwiw, dbt1 (OVH public cloud) does have AES-NI support enabled.

So, for TLS 1.3 we are looking at the following ciphers (credits MozillaWiki):

0x13,0x01  -  TLS_AES_128_GCM_SHA256        TLSv1.3  Kx=any  Au=any  Enc=AESGCM(128)             Mac=AEAD
0x13,0x02  -  TLS_AES_256_GCM_SHA384        TLSv1.3  Kx=any  Au=any  Enc=AESGCM(256)             Mac=AEAD
0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256  TLSv1.3  Kx=any  Au=any  Enc=CHACHA20/POLY1305(256)  Mac=AEAD

On systems without AES-NI, ChaCha20 would be preferred, while the contrary seems to be true for modern systems - with AES-NI. Only modern systems connect to MariaDB, so AES ciphers should be considered (but only 100% sure if we can enable AES-NI on KVM guests!).

Comparison between -128 and -256 on cloud1 - KVM host (median of three runs, picking 8192 bytes value):

TypeBytes/s%diff - aes-128-gcm%diff - aes-256-gcm%diff - chacha20-poly1305%diff KVM guest

Comparison between -128 and -256 on db6 - KVM guest, no AES-NI (median of three runs, picking 8192 bytes value):

TypeBytes/s%diff - aes-128-gcm%diff - aes-256-gcm%diff - chacha20-poly1305%diff KVM host


  • aes-128-gcm yields between 21% and 35% better results than aes-256-gcm
  • chacha20-poly1305 works better than aes-128-gcm (+152.1%) and aes-256-gcm (+205.7%) on Proxmox VMs, due to lack of AES-NI
  • On hosts with AES-NI, aes-256-gcm is 2265% faster than chacha20-poly1305, aes-128-gcm even being 2537% faster!!

Eventually, the following tasks are left:

  1. Find out if all applications (MediaWiki, Matomo, Icinga, etc.) support the combination of TLS 1.3 and the aforementioned ciphers.
  2. Think about enabling AES-NI on the KVM guests.
  3. Debate whether the performance hit of AES-256 is 'worth the extra security'.
  4. Ensure ALL user accounts (except root user) require TLS upon connecting.
  5. Do the same, but for the root user. In order for local connections (/root/.my.cnf) to work with server verification, one must always connect through the FQDN (e.g. sudo -i mysql -h instead of sudo -i mysql). However, currently connections are denied since root only accepts connections from localhost.

Ideally, one would not be using our wildcard certificates for MariaDB, but I don't think maintaining our own certificate authority is a good idea either. Perhaps go with Let's Encrypt TLS certificates issued for db([67]|t1)

For testing, @Paladox has enabled AES-NI on the MediaWiki servers and test2.


UserSource of connectionsCurrent TLS specsSupports TLS 1.3 w/ AES-{128,256}-GCM?
grafana@%Grafana app (monX)??
icinga@%Icinga monitoring agents/scripts (monX)??
icinga2@%Icinga master config (monX)??
icingaweb2@%Icinga web interface? (monX)Does not use TLS: puppet says yes, but the config is incorrect (and tcpdump verifies plaintext data)?
mediawiki@%MediaWiki app (mwX/testX)(hack in DatabaseMysqli.php on test2): TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256No, TLS 1.3 is PHP 7.4+?
phabricator@%Phabricator app (phabX)?No, TLS 1.3 is PHP 7.4+?
piwik@%Matomo app (monX)?No, TLS 1.3 is PHP 7.4+?
replica@%Database replication (dbbackupX)?MariaDB master: (openssl s_client -starttls mysql) TLS_AES_128_GCM_SHA256 supported, TLS_AES_256_GCM_SHA384 supported. Replica connections unknwon.
root@localhostRoot access (mysql client on server)No TLS (but that's expected)Is supported (via local mysql client)
wikiadmin@%MediaWiki maintenance & jobrunner (jobrunnerX)sql.php (jobrunner1): TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256No, TLS 1.3 is PHP 7.4+?
roundcubemail@{2001:41d0:800:1056::9,}Roundcube webmail (mailX)No TLS, has TLS supportNo, TLS 1.3 is PHP 7.4+?
Southparkfan lowered the priority of this task from Normal to Low.Feb 26 2021, 21:47