It is recommended to use the encrypted connection to ensure data security because non-encrypted connection might lead to information leak.
The TiDB server supports the encrypted connection based on the TLS (Transport Layer Security). The protocol is consistent with MySQL encrypted connections and is directly supported by existing MySQL clients such as MySQL operation tools and MySQL drivers. TLS is sometimes referred to as SSL (Secure Sockets Layer). Because the SSL protocol has known security vulnerabilities, TiDB does not support it. TiDB supports the following versions: TLS 1.0, TLS 1.1, and TLS 1.2.
After using an encrypted connection, the connection has the following security properties:
The encrypted connections in TiDB are disabled by default. To use encrypted connections in the client, you must first configure the TiDB server and enable encrypted connections. In addition, similar to MySQL, the encrypted connections in TiDB consist of single optional connection. For a TiDB server with encrypted connections enabled, you can choose to securely connect to the TiDB server through an encrypted connection, or to use a generally unencrypted connection. Most MySQL clients do not use encrypted connections by default, so generally the client is explicitly required to use an encrypted connection.
In short, to use encrypted connections, both of the following conditions must be met:
See the following desrciptions about the related parameters to enable encrypted connections:
ssl-cert: specifies the file path of the SSL certificate
ssl-key: specifies the private key that matches the certificate
ssl-ca: (optional) specifies the file path of the trusted CA certificate
To enable encrypted connections in the TiDB server, you must specify both of the
ssl-key parameters in the configuration file when you start the TiDB server. You can also specify the
ssl-ca parameter for client authentication (see Enable authentication).
All the files specified by the parameters are in PEM (Privacy Enhanced Mail) format. Currently, TiDB does not support the import of a password-protected private key, so it is required to provide a private key file without a password. If the certificate or private key is invalid, the TiDB server starts as usual, but the client cannot connect to the TiDB server through an encrypted connection.
The certificate or key is signed and generated using OpenSSL, or quickly generated using the
mysql_ssl_rsa_setup tool in MySQL:
This command generates the following files in the
certs ├── ca-key.pem ├── ca.pem ├── client-cert.pem ├── client-key.pem ├── private_key.pem ├── public_key.pem ├── server-cert.pem └── server-key.pem
The corresponding TiDB configuration file parameters are:
[security] ssl-cert = "certs/server-cert.pem" ssl-key = "certs/server-key.pem"
If the certificate parameters are correct, TiDB outputs
Secure connection is enabled when started, otherwise it outputs
Secure connection is NOT ENABLED.
The client of MySQL 5.7 or later versions attempts to establish an encrypted connection by default. If the server does not support encrypted connections, it automatically returns to unencrypted connections. The client of MySQL earlier than version 5.7 uses the unencrypted connection by default.
You can change the connection behavior of the client using the following
--ssl-mode=REQUIRED: The client requires an encrypted connection. The connection cannot be established if the server side does not support encrypted connections.
--ssl-modeparameter: The client attempts to use an encrypted connection, but the encrypted connection cannot be established if the server side does not support encrypted connections. Then the client uses an unencrypted connection.
--ssl-mode=DISABLED: The client uses an unencrypted connection.
For more information, see Client-Side Configuration for Encrypted Connections in MySQL.
ssl-ca parameter is not specified in the TiDB server or MySQL client, the client or the server does not perform authentication by default and cannot prevent man-in-the-middle attack. For example, the client might “securely” connect to a disguised client. You can configure the
ssl-ca parameter for authentication in the server and client. Generally, you only need to authenticate the server, but you can also authenticate the client to further enhance the security.
To authenticate the TiDB server from the MySQL client:
ssl-keyparameters in the TiDB server.
--ssl-caparameter in the MySQL client.
VERIFY_IDENTITYin the MySQL client.
ssl-cert) configured by the TiDB server is signed by the CA specified by the client
--ssl-caparameter, otherwise the authentication fails.
To authenticate the MySQL client from the TiDB server:
ssl-caparameters in the TiDB server.
--ssl-keyparameters in the client.
ssl-caspecified by the server.
To perform mutual authentication, meet both of the above requirements.
Note: Currently, it is optional that TiDB server authenticates the client. If the client does not present its identity certificate in the TLS handshake, the TLS connection can also be successfully established.
SHOW STATUS LIKE "%Ssl%"; statement to get the details of the current connection, including whether encryption is used, the encryption protocol used by encrypted connections, the TLS version number and so on.
See the following example of the result in an encrypted connection. The results change according to different TLS versions or encryption protocols supported by the client.
mysql> SHOW STATUS LIKE "%Ssl%"; ...... | Ssl_verify_mode | 5 | | Ssl_version | TLSv1.2 | | Ssl_cipher | ECDHE-RSA-AES128-GCM-SHA256 | ......
For the official MySQL client, you can also use the
\s statement to view the connection status:
mysql> \s ... SSL: Cipher in use is ECDHE-RSA-AES128-GCM-SHA256 ...
The TLS versions, key exchange protocols and encryption algorithms supported by TiDB are determined by the official Golang libraries.
What’s on this page