2

When setting up new MySQL or MariaDB servers, I am much more concerned about security than performance. The MySQL and MariaDB documentation use the words "allow" and "permit" around all the SSL options, where I would much rather see "require".

I am looking for something like, "mysqld --ssl-mode=REQUIRE" but that apparently doesn't work [anymore?] because the logs say that's a bad option. I am not looking to do this per-user, I'm looking to do it for the whole system, no matter what.

I should point out that all of my certificates are working fine, and I've verified that all of that works. It's just that now, I would like to REQUIRE it be used, always, by everyone, period, strictly, no exceptions, no, not even that one, yes really. Remote? Encrypt. Localhost? Encrypt. Root? Encrypt. Somebody else? Encrypt. In short: connected to anything at all for any reason? Encrypt.

Does anybody know of a master switch to require this all the time, period?

Again, I am not looking for per-user options-- that's exactly what I'm hoping to avoid. This is for an embedded device that may be in service for an extended period of time, and the less branching logic, the better. "Always" tends to have fewer edge cases.

Thanks!

Improve this question

3 Answers 3

Reset to default
1

As of MySQL 5.7, it does not seem to be possible to force SSL from the server side, without specifying it for each user.

https://dev.mysql.com/doc/refman/5.7/en/encrypted-connection-options.html#option_general_ssl-mode

--ssl-mode=mode

This option is available only for client programs, not the server. It specifies the security state of the connection to the server. These option values are permitted:

BOO. You can only force SSL from the client side. Opposite of what you want to do. This is likely why you're getting "bad option" trying to use it as a server setting.

Also:

To require use of encrypted connections by a MySQL account, use CREATE USER to create the account with a REQUIRE SSL clause, or use ALTER USER for an existing account to add a REQUIRE SSL clause. Connection attempts by clients that use the account will be rejected unless MySQL supports encrypted connections and an encrypted connection can be established.

Enforcing users to Require SSL by routinely checking the users table for REQUIRE SSL seems hacky, but it might be your best option.

Improve this answer
2
  • Nope, that's specifically what I DON'T want to do. However, I came to the same conclusion: that's the only approach supported. It DID occur to me, however, that I might be able to craft a stateful firewall rule that denies the insecure connections... Thanks for checking my work.
    – breakpoint
    Sep 26, 2017 at 23:45
  • Someone, please tell us we're wrong!
    – breakpoint
    Sep 26, 2017 at 23:50
0

https://dev.mysql.com/doc/refman/5.7/en/encrypted-connection-protocols-ciphers.html seems to say you can force a particluar version via the VARIABLE tls_version, with values such as TLSv1,TLSv1.1,TLSv1.2. (This is unlike the suggestion you envisioned.)

If that is not sufficient, here are more references:

https://dev.mysql.com/doc/refman/5.7/en/encrypted-connections.html

Percona Changelog

----- 2016-07-07 Perc 5.6.31-77.0 -- New Features -- -----

Percona Server has implemented protocol support for TLS 1.1 and TLS 1.2. This implementation turns off TLS v1.0 support by default.

MySQL Changelogs:

----- 2016-07-29 5.7.14 General Availability -- X Plugin Notes -- -----

When using SSL, only TLSv1 connections were being accepted. The fix ensures that all TLS versions supported by the server are accepted. (Bug #23524243)

----- 2016-07-29 5.7.14 General Availability -- Bugs Fixed -- Replication -----

Slaves running MySQL version 5.7.11 and later were always using SSL/TLS when the server supported it, regardless of the MASTER_SSL option. This was due to the addition of the --ssl-mode option, which defaults to preferring an SSL connection. The fix ensures that slaves do not use SSL when MASTER_SSL=0. (Bug #81223, Bug #23197529)

----- 2016-06-02 5.7.13 General Availability -- Bugs Fixed -- -----

The mysql_read_defaults_options() function was missing a break statement, causing any option value for the --ssl-cipher option also to be applied to the --tls-version option, with unpredictable results. (Bug #81139, Bug #23129821)

----- 2015-12-07 5.7.10 General Availability -- Security Notes -- -----

Previously, MySQL supported only the TLSv1 protocol for encrypting secure connections. TLS support is now extended to enable a higher level of encrypted connection security: When compiled using OpenSSL 1.0.1 or higher, MySQL supports the TLSv1, TLSv1.1, and TLSv1.2 protocols.

When compiled using the bundled version of yaSSL, MySQL supports the TLSv1 and TLSv1.1 protocols.

Because TLSv1.2 requires OpenSSL, support for this protocol is available in binary distributions only for MySQL Commercial Server, and not for MySQL Community Server (which is compiled using yaSSL). To enable TLSv1.2 support if you build from source, you must set the WITH_SSL CMake option to use OpenSSL.

The tls_version system variable enables specifying at startup the TLS protocols permitted by the server. On the client side, the --tls-version option enables specifying the TLS protocols permitted per client invocation.

The new MASTER_TLS_VERSION option for the CHANGE MASTER TO statement specifies the encryption protocols permitted by the master for slave connections.

The mysql_options() C API function has a new MYSQL_OPT_TLS_VERSION option that enables specifying from within the client library the TLS protocols permitted by a client program.

By default, MySQL attempts to use the highest TLS protocol version available, depending on which SSL library was used to compile the server and client, which key size is used, and whether the server or client are restricted from using some protocols; for example, by means of tls_version/--tls-version.

For more information, see Secure Connection Protocols and Ciphers.

MariaDB Changelogs

It appears that MariaDB 10.2 has picked up the TLS code, though I can't tell if it is up to date with the above. Previously:

----- 2014-12-21 MariaDB 5.5.41 & 2014-11-25 MariaDB 10.0.15 -- -- -----

MDEV-6975 Implement TLS protocol

----- 2014-11-25 MariaDB 10.0.15 -- -- -----

MDEV-6975 Implement TLS protocol Revision #4500.1.22 [merge] Thu 2014-11-20 16:07:34 +0100 5.5 merge

Improve this answer
2
  • That's right-- ridiculously, you can deny usage of the older secure method, but you cannot deny usage of the completely insecure method. Ludicrous, but apparently how it is!
    – breakpoint
    Sep 26, 2017 at 23:49
  • It is hard to believe it is 2019 and we still can't get well configured out of the box. What the hell have the MySQL dev's been doing? Don't they follow the news? Do they feel threats somehow don't apply to them?
    – user141074
    Mar 16, 2019 at 11:59
0

use:

require_secure_transport=ON

in the my.cnf

https://dev.mysql.com/doc/refman/5.7/en/using-encrypted-connections.html

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.