With an unencrypted connection between the MySQL client and the server, someone with access to the network could watch all your traffic and inspect the data being sent or received between client and server.
When you must move information over a network in a secure fashion, an unencrypted connection is unacceptable. To make any kind of data unreadable, use encryption. Encryption algorithms must include security elements to resist many kinds of known attacks such as changing the order of encrypted messages or replaying data twice.
MySQL supports secure (encrypted) connections between clients and the server using the TLS (Transport Layer Security) protocol. TLS is sometimes referred to as SSL (Secure Sockets Layer) but MySQL does not actually use the SSL protocol for secure connections because it provides weak encryption (see Section 22.214.171.124, “Secure Connection Protocols and Ciphers”).
TLS uses encryption algorithms to ensure that data received over a public network can be trusted. It has mechanisms to detect data change, loss, or replay. TLS also incorporates algorithms that provide identity verification using the X509 standard.
X509 makes it possible to identify someone on the Internet. In basic terms, there should be some entity called a “Certificate Authority” (or CA) that assigns electronic certificates to anyone who needs them. Certificates rely on asymmetric encryption algorithms that have two encryption keys (a public key and a secret key). A certificate owner can present the certificate to another party as proof of identity. A certificate consists of its owner's public key. Any data encrypted using this public key can be decrypted only using the corresponding secret key, which is held by the owner of the certificate.
MySQL can be compiled for secure-connection support using OpenSSL or yaSSL. For a comparison of the two packages, see Section 126.96.36.199, “OpenSSL Versus yaSSL” For information about the encryption protocols and ciphers each package supports, see Section 188.8.131.52, “Secure Connection Protocols and Ciphers”.
MySQL performs encryption on a per-connection basis, and use of
encryption for a given user can be optional or mandatory. This
enables you to choose an encrypted or unencrypted connection
according to the requirements of individual applications. For
information on how to require users to use encrypted connections,
see the discussion of the
REQUIRE clause of the
CREATE USER statement in
Section 184.108.40.206, “CREATE USER Syntax”. See also the description of the
variable at Section 6.1.4, “Server System Variables”
Several improvements were made to secure-connection support in MySQL 5.7. The following timeline summarizes the changes:
5.7.3: On the client side, an explicit
--ssloption is no longer advisory but prescriptive. Given a server enabled to support secure connections, a client program can require a secure conection by specifying only the
--ssloption. The connection attempt fails if a secure connection cannot be established. Other
--ssl-options on the client side mean that a secure connection is advisory (the connection attempt falls back to an unencrypted connection if a secure connection cannot be established).
5.7.5: The server-side
--ssloption value is enabled by default.
For servers compiled using OpenSSL, the
sha256_password_auto_generate_rsa_keyssystem variables are available to enable autogeneration and autodiscovery of SSL/RSA certificate and key files at startup. For certificate and key autodiscovery, if
--sslis enabled and other
--ssl-options are not given to configure secure connections explicitly, the server attempts to enable support for secure connections automatically at startup if it discovers the requisite certificate and key files in the data directory.
5.7.6: The mysql_ssl_rsa_setup utility is available to make it easier to manually generate SSL/RSA certificate and key files. Autodiscovery of SSL/RSA files at startup is expanded to apply to all servers, whether compiled using OpenSSL or yaSSL. (This means that
auto_generate_certsneed not be enabled for autodiscovery to occur.)
If the server discovers at startup that the CA certificate is self-signed, it writes a warning to its error log. (The certificate will be self-signed if created automatically by the server or manually using mysql_ssl_rsa_setup.)
5.7.7: The C client library attempts to establish a secure connection by default whenever the server supports secure connections. This affects client programs as follows:
In the absence of an
--ssloption, the client falls back to an unencrypted connection if a secure connection cannot be established.
This change also affects subsequent releases of MySQL Connectors that are based on the C client library: Connector/C, Connector/C++, and Connector/ODBC.
require_secure_transportsystem variable is available to control whether client connections to the server must use some form of secure transport.
5.7.10: TLS protocol support is extended from TLSv1 to also include TLSv1.1 and TLSv1.2. The
tls_versionsystem variable on the server side and
--tls-versionoption on the client side enable the level of support to be selected. See Section 220.127.116.11, “Secure Connection Protocols and Ciphers”.
5.7.11: MySQL client programs support an
--ssl-modeoption that enables you to specify the security state of the connection to the server. The
--ssl-modeoption comprises the capabilities of the client-side
--ssl-verify-server-certoptions. Consequently, both of those options are deprecated and will be removed in a future MySQL release.
Replication uses the C API, so secure connections can be used between master and slave servers. See Section 18.3.8, “Setting Up Replication to Use Secure Connections”.
It is also possible to connect securely from within an SSH connection to the MySQL server host. For an example, see Section 7.3.13, “Connecting to MySQL Remotely from Windows with SSH”.