In MySQL server 8.2.0, we have made certain changes to promote usage of secure and robust ciphers in MySQL server.
If you are relying on the default cipher settings in MySQL server and client, you can stop here. These changes will not have any impact on your usecase. On the other hand, if you have configured TLSv1.2 or TLSv1.3 ciphers in your deployment, following information might be of your interest.
MySQL has always promoted usage of ciphers that provide best possible security. From time to time, we have updated set of ciphers supported. We also block usage of ciphers deemed weak. E.g. MySQL has already blocked usage of weak ciphers - even prior to MySQL 8.2.0. If you try to start server/client with any of the these ciphers, TLS connection won't be possible. These ciphers are of following categories:
Blocked Ciphers Categories
- Anonymous cipher suites, such as anonymous DH and anonymous ECDH algorithms
- Ciphers with NULL encryption
- Export encryption algorithms; includes 40 and 56 bits algorithms
- “low” encryption cipher suites; includes those using 64 or 56 bit encryption algorithms that are not covered by export cipher suites
- Cipher suites using MD5/DES/3DES/RC2/RC4
- Cipher suites using pre-shared keys (PSK)
What's new in MySQL 8.2.0?
Starting with MySQL 8.2.0, in order to provide better security, server by default uses only those ciphers that satisfy following properties:
Keeping these conditions in mind, Following are the lists of ciphers supported by default (in order of priority):
*Notes about TLSv1.2 ciphers
- Actual set of ciphers available for use depend on TLS certificate(RSA or ECDSA) used.
- Cipher support depends on OpenSSL library used by given MySQL package.
E.g. our RPM packages for EL7 links against system OpenSSL libraries and that's OpenSSL 1.0.2. So CHACHA20 and CCM based ciphers are not supported on EL7 because they are not supported by underlying OpenSSL library itself.
In addition, ciphers that use non-ephemeral DH are no longer permissible and are always blocked on both, server and client.
If server detects a cipher that's not part of the default lists, it will display a deprecation warning on server's error log notifying the same.
This check is done at following ocassions:
- When MySQL server starts
- When ciphers are configured using SET statement for following variables:
Very soon, we intend to completely block usage of ciphers that are abcent from the default lists above. Hence, if your deployment uses such ciphers, you should consider switching to one of the more secure ciphers at the earliest opportunity. Better yet: as security is always evolving, just rely on the default list - which too would evolve over time.
For backward compatibility reasons, libmysqlclient would continue to support following additional ciphers:
Additional client side ciphers
This will allow clients to connect to an earlier version of server configured to use non-default ciphers. However, strong ciphers mentioned earlier are ALWAYS preferred whenever available.
We hope that these changes contribute toward making your deployment more secure.