MySQL Bugs: #118886: TLS connections still allowed after dynamically setting tls

Bug #118886	TLS connections still allowed after dynamically setting tls_version to blank string
Submitted:	24 Aug 16:58	Modified:	8 Oct 15:29
Reporter:	Evan Elias	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Connection Handling	Severity:	S3 (Non-critical)
Version:	8.0, 8.4	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The manual states that setting tls_version to an empty string should disable TLS connections:

"If you set a TLS version parameter to the empty string, encrypted connections cannot be established ... * tls_version: The server does not permit encrypted incoming connections." - https://dev.mysql.com/doc/refman/8.4/en/encrypted-connection-protocols-ciphers.html

"Setting this variable to an empty string disables encrypted connections." - https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tls_version

The tls_version variable is dynamic in MySQL 8.0.16+. However, after running this dynamically,

SET GLOBAL tls_version = '';

...TLS connections can still be established fine, and it does not seem to have any effect.

Other text on https://dev.mysql.com/doc/refman/8.4/en/encrypted-connection-protocols-ciphers.html is confusingly contradictory: one section says "To change the value of tls_version, set it at server startup" and then a few paragraphs later it says "tls_version can be changed at runtime". Possibly a documentation oversight from the 8.0.16 change.

How to repeat:
Run SET GLOBAL tls_version = '';

And then note that TLS connections can still be established, e.g. by running the mysql client with --ssl-mode=required, and/or by checking session status.

Suggested fix:
Dynamic setting of tls_version to empty string should block subsequent encrypted connections, just like setting it at startup. Or if this is not possible to disable dynamically, the manual should reflect this, and ideally an error should be returned by this SET command in this situation.

Hi,
Thank you for your report.

Posted by developer:

Now, just setting the global variable to a new value doesn't make it effective by itself (see the docs link at the end of this). To activate the new value you need to execute ALTER INSTANCE RELOAD TLS.
The issue is that, when you set the TLS version to an empty string and you then execute ALTER INSTANCE RELOAD TLS you get:

mysql> alter instance reload tls;
ERROR 3888 (HY000): Failed to set up SSL because of the following SSL library error: TLS version is invalid

This works only when the --tls-version=' is specified at the command line. You get:

2025-10-08T11:24:38.015202Z 0 [Warning] [MY-013595] [Server] Failed to initialize TLS for channel: mysql_main. See below for the description of exact issue.
2025-10-08T11:24:38.015236Z 0 [Warning] [MY-010069] [Server] Failed to set up SSL because of the following SSL library error: TLS version is invalid

And, consequently:
mysql> select * from performance_schema.tls_channel_status;
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id: 9
Current database: *** NONE ***

One can of course argue that this should also happen when you execute ALTER INSTANCE RELOAD TLS. If you think that specifying the option at the command line is not a good enough workaround, please file a feature request to make this happen: disable the TLS channel if any of the configuration values specified is invalid.

Below are some links to the relevant docs:

https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-c... says:

To reconfigure the TLS context at runtime, use this procedure:

Set each TLS context-related system variable that should be changed to its new value.

Execute ALTER INSTANCE RELOAD TLS. This statement reconfigures the active TLS context from the current values of the TLS context-related system variables. It also sets the context-related status variables to reflect the new active context values. The statement requires the CONNECTION_ADMIN privilege.

New connections established after execution of ALTER INSTANCE RELOAD TLS use the new TLS context. Existing connections remain unaffected. If existing connections should be terminated, use the KILL statement.

Thank you, Georgi. After reading the manual page for ALTER INSTANCE, it seems my goal is already achievable dynamically at runtime through this relatively obscure syntax that I hadn't ever noticed previously:

SET GLOBAL tls_version = '';
ALTER INSTANCE RELOAD TLS NO ROLLBACK ON ERROR;

After running that with the NO ROLLBACK ON ERROR clause, I can confirm that new connections with --ssl-mode=required are properly rejected.

Just for background context, my use-case here involves integration testing coverage for various combinations with and without TLS between the client and server side. Restarting the server would be problematic due to how my tests are executed on a Dockerized server container with a tmpfs data mount. But separately I've also encountered other situations where doing this dynamically could be useful.

So, happily this works as-is, and I agree it is not a server bug, and there's also no need for a feature request.

I would however kindly request that the server variable reference for tls_version at https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tls_version could be clarified to mention ALTER INSTANCE RELOAD TLS. Most of the other SSL/TLS variables on that page specifically mention the ALTER INSTANCE RELOAD TLS syntax, but the entry for tls_version does not mention that syntax directly. From a casual read of that manual entry, I had expected it to work immediately, like any other dynamic variable.

If this seems reasonable, please consider converting this to an open documentation bug. Thanks!