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? https://cipherli.st recommends EECDH+AESGCM:EDH+AESGCM, though a performance comparison is crucial.

Per @Southparkfan

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 https://wiki.mozilla.org/Security/Server_Side_TLS, 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 https://github.com/mdaxini/howto-openssl/wiki/OpenSSL-Cipher-Speed. 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):

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

Conclusions:

• 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 db6.miraheze.org 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).miraheze.org?

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

db13

TLS setup is mostly well-defined for MariaDB. The length this task has been opened has meant it has lost its original purpose and the constant recycling of it has meant the purpose and end target is undefined.

Therefore I will redefine the task as follows:

TLS is fully configured on db*.
Clients aren't required to use TLS. This should change.

TLS is now configured so only 1.2 and 1.3 can be used, and root has SSL encryption:

MariaDB [(none)]> SHOW SESSION STATUS LIKE 'Ssl_cipher';
+---------------+------------------------+
| Variable_name | Value                  |
+---------------+------------------------+
| Ssl_cipher    | TLS_AES_256_GCM_SHA384 |
+---------------+------------------------+
1 row in set (0.000 sec)

Therefore now the task is only blocked on requiring all user accounts have TLS when connecting. List of accounts are:

• root
• icinga
• exporter
• replica
• dbbackup_user
• grafana
• icinga2
• icingaweb2
• mediawiki
• wikiadmin
• phabricator
• piwik
• roundcubemail

Phabricator can not be done as it does not support MySQL SSL connections at all in the code.