I had an error being reported consistently in a mysqld.log file that relates to MySQL TLS Connections on Localhost.
A deprecated TLS version TLSv1 is enabled for channel mysql_main
A deprecated TLS version TLSv1.1 is enabled for channel mysql_mainA question is why an up-to-date CloudLinux server has older / insecure TLS versions enabled at all ? In any case, why would localhost connections need TLS?
Related discussions that are, at least to me, inconclusive.
https://serverfault.com/questions/1012073/mariadb-tls-and-localhost-connection
The result of these threads is that the focus is on using TLS in order to prevent man-in-the-middle, or network stream monitoring. The question of relevance to an enclosed system on a single server without remote access is redirected to why you should have SSL for remote connections.
The underlying thought here is that TLS (SSL) security on MySQL traffic that is only ever on locahost can only be compromised if the server is already compromised, and if the server is already compromised, then they can read the DB files directly and do not need to bother with decrypting a SQL data stream. Which is also kind of wrong, as the local connection will be directly to port 3306 (default for MySQL) and not be transmitted via TCP anyway.
That said, some of the commentary in the threads seem to support my thinking that TLS on a localhost configuration is a waste of performance overhead and serves very little or nothing related to security.
How much of a performance hit is the next question, and I think it is summed up in Ernie Souhrada’s article at Percona on SSL Performance Overhead in MySQL where he says “However, I definitely didn’t think the encryption overhead would be so high.”
Daniel van Eeden presents some more data in MySQL and SSL/TLS Performance that supports the performance hit that security creates, but provides some ideas for mitigation.
The basic Security Guidelines provided at https://dev.mysql.com/doc/refman/5.7/en/security-guidelines.html are a good place to start.
Coming back to the actual error lines being logged a check of the config for mysqld shows:
# mysqld --help --verbose | grep TLS
TLS v1.3 ciphersuite to use (implies --ssl) for
TLS version for --admin-port, permitted values are TLSv1,
TLSv1.1, TLSv1.2, TLSv1.3
are SSL/TLS, Unix socket or Shared Memory (on Windows).
TLS v1.3 ciphersuite to use (implies --ssl)
--tls-version=name TLS version, permitted values are TLSv1, TLSv1.1,
TLSv1.2, TLSv1.3
admin-tls-version TLSv1,TLSv1.1,TLSv1.2,TLSv1.3
tls-version TLSv1,TLSv1.1,TLSv1.2,TLSv1.3
Which indicates that the config is loading all the TLS versions as acceptable. A quick read over at dev.mysql.com TLS documentation provided more information to review and reset the options:
mysql> SHOW GLOBAL VARIABLES LIKE 'tls_version';
+---------------+-------------------------------+
| Variable_name | Value |
+---------------+-------------------------------+
| tls_version | TLSv1,TLSv1.1,TLSv1.2,TLSv1.3 |
+---------------+-------------------------------+
1 row in set (0.01 sec)
mysql> SELECT * FROM performance_schema.session_status
-> WHERE VARIABLE_NAME IN ('Ssl_version','Ssl_cipher');
+---------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+---------------+----------------+
| Ssl_cipher | |
| Ssl_version | |
+---------------+----------------+
2 rows in set (0.00 sec)
These two queries confirm that the default selection is ALL TLS versions and that none of the Current Client Sessions are using SSL (hark back to the bit about port 3306 and not using TCP locally).
This is addressed by updating the /etc/my.cnf file with a single line:
tls_version=TLSv1.2,TLSv1.3
and a subsequent restart of mysql service.
So even though we are not using SSL / TLS as such, having only the currently recommended TLS versions enabled will stop MySQL complaining in the log file.