Client's --ssl-* options (without --ssl-verify-server-cert) are silently ignored if TLS is not possible

If the client provides --ssl-* options, but a TLS connection to the server is not possible, then the client simply silently ignores the provided --ssl-* options if the --ssl-verify-server-cert option is not also provided. The user may think that their connection is encrypted, but it is not.

The current behavior is probably the "expected" behavior according to Engineering. See MDEV-16409 for some details on previous discussion. However, I don't think this behavior is the behavior that would be expected by most users. When implementing security features, the industry standard for design is to fail safe. Security features may be mandatory for compliance reasons, and the fault of a security control may silently increase risk.

Consider an example: if you typed https://mybank.com into your browser's URL bar, would you be happy if the browser silently used an unencrypted connection, even though you requested HTTPS? This is basically what MariaDB's clients are doing.

For example, let's say that TLS is not enabled on our server:

$ sudo mariadb --execute="SHOW GLOBAL VARIABLES LIKE 'ssl%'"

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| ssl_ca        |       |

| ssl_capath    |       |

| ssl_cert      |       |

| ssl_cipher    |       |

| ssl_crl       |       |

| ssl_crlpath   |       |

| ssl_key       |       |

+---------------+-------+

If a client tries to connect via TLS, then they will not see an error, and their connection will be unencrypted:

$ mariadb --user=myuser --password=password --host=127.0.0.1 --ssl --ssl-ca=/home/vagrant/ca.pem --execute="SHOW SESSION STATUS LIKE 'Ssl_cipher'"

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Ssl_cipher    |       |

+---------------+-------+

The client will only see an error if they also provide the --ssl-verify-server-cert option:

$ mariadb --user=myuser --password=password --host=127.0.0.1 --ssl --ssl-ca=/home/vagrant/ca.pem --ssl-verify-server-cert --execute="SHOW SESSION STATUS LIKE 'Ssl_cipher'"

ERROR 2026 (HY000): SSL connection error: SSL is required, but the server does not support it

MySQL fixed this problem by introducing the --ssl-mode client option in MySQL 5.7.11 that provides more configurable TLS behavior.

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

Part of the new MySQL behavior made it so that if the client specifies the --ssl-ca or --ssl-capath option, then that will imply --ssl-mode=VERIFY_CA. by default.

The --ssl-mode option interacts with CA certificate options as follows:

• If --ssl-mode is not explicitly set otherwise, use of --ssl-ca or --ssl-capath implies --ssl-mode=VERIFY_CA.

• For --ssl-mode values of VERIFY_CA or VERIFY_IDENTITY, --ssl-ca or --ssl-capath is also required, to supply a CA certificate that matches the one used by the server.

• An explicit --ssl-mode option with a value other than VERIFY_CA or VERIFY_IDENTITY, together with an explicit --ssl-ca or --ssl-capath option, produces a warning that no verification of the server certificate will be done, despite a CA certificate option being specified.

In my opinion, we should take one of the following actions:

• Throw a warning if the client provides --ssl-* options, but a TLS connection to the server is not possible.

• Or make the --ssl-ca and --ssl-capath options imply the --ssl-verify-server-cert option by default (similar to MySQL 5.7+ behavior).

• Or port MySQL's --ssl-mode behavior.