- Documentation Library
- Table of Contents
- MySQL 5.5 Manual
- MySQL 5.4 Manual
- MySQL 5.1 Manual
- MySQL 5.0 Manual
- MySQL 3.23/4.0/4.1 Manual
- Table of Contents
- 5.6 MySQL User Account Management
- 5.6.1 User Names and Passwords
- 5.6.2 Adding User Accounts
- 5.6.3 Removing User Accounts
- 5.6.4 Setting Account Resource Limits
- 5.6.5 Assigning Account Passwords
- 5.6.6 Using SSL for Secure Connections
- 5.6.7 Connecting to MySQL Remotely from Windows with SSH
- 5.6.8 Auditing MySQL Account Activity
[+/-]
Beginning with version 4.0.0, MySQL has support for secure
(encrypted) connections between MySQL clients and the server using
the Secure Sockets Layer (SSL) protocol. This section discusses
how to use SSL connections. For information on how to require
users to use SSL connections, see the discussion of the
REQUIRE clause of the
GRANT statement in
Section 12.4.1.2, “GRANT Syntax”.
The standard configuration of MySQL is intended to be as fast as possible, so encrypted connections are not used by default. Doing so would make the client/server protocol much slower. Encrypting data is a CPU-intensive operation that requires the computer to do additional work and can delay other MySQL tasks. For applications that require the security provided by encrypted connections, the extra computation is warranted.
MySQL allows encryption to be enabled on a per-connection basis. You can choose a normal unencrypted connection or a secure encrypted SSL connection according the requirements of individual applications.
Secure connections are based on the OpenSSL API and are available through the MySQL C API. Replication uses the C API, so secure connections can be used between master and slave servers.
Another way to connect securely is from within an SSH connection to the MySQL server host. For an example, see Section 5.6.7, “Connecting to MySQL Remotely from Windows with SSH”.
User Comments
If you plan to use SSL connections for remote connections to a MySQL DB with iptables firewall, you should be aware of a slight quirk that may bite on an iptables restart.
In certain distros iptables appears to manage to lose the connection tracking information when the service is restarted. This can result in packets that should be associated with a connection being dropped and will appear as though the client connection is stuck waiting for a response from the server.
The trick is to either use stateless rules for tcp, or to make sure the firewall on the client explicitly permits packets arriving from the server address with source port 3306 (or whatever port the server is running on).
This problem only occurs with V4 clients when using SSL authenticated connections. V5 clients or non-SSL connections don't suffer from the same issue.
Add your own comment.