The documentation suggests that when requesting a specific cipher to be used with

mysql ... --ssl-cipher=...

the connection will either use one of the explicitly listed ciphers, or fail.

When the client tries to connect using TLSv1.3 it always adds the following three ciphers to the cipher list in its TLS "Client Hello" packet though:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

and the server picks TLS_AES_256_GCM_SHA384 as the next best option if the originally requested cipher is not supported by it.

So client and server use a totally different cipher than the one explicitly requested without failing, or otherwise complaining about this at all.

As far as I remember this auto-adding of the three extra ciphers may actually be documented, or even required, TLSv1.3 behavior, but I can't find right now where I have read about this.

If this is the case we may only need to change the documentation to say that in case of TLSv1.3 a different cipher may be chosen instead of failing when the requested cipher is not available.

Otherwise, as the actual addition of extra ciphers seems to be done by OpenSSL, not our client code, the client should explicitly check whether the cipher being used matches the one, or one of those, requested with --ssl-cipher, and terminate the connection with an error message if this is not the case even when an encrypted connection could be established.