In this blog post, we’ll look at enabling Percona XtraDB Cluster SST Traffic Encryption, and some of the changes to the SSL-based encryption of SST traffic in Percona XtraDB Cluster 5.7.16.
Some background
Percona XtraDB Cluster versions prior to 5.7 support encryption methods 0, 1, 2 and 3:
- encrypt = 0 : (default) No encryption
- encrypt = 1 : Symmetric encryption using AES-128, user-supplied key
- encrypt = 2 : SSL-based encryption with a CA and cert files (via socat)
- encrypt = 3 : SSL-based encryption with cert and key files (via socat)
We are deprecating modes encrypt=1,2,3 in favor of the new mode, encrypt=4. “encrypt=3” is not recommended, since it does not verify the cert being used (it cannot verify since no Certificate Authority (CA) file is provided). “encrypt=2” and “encrypt=3” use a slightly different way of building the SSL files than MySQL does. In order to remove confusion, we’ve deprecated these modes in favor of “encrypt=4”, which can use the MySQL generated SSL files.
New feature: encrypt= 4
The previous SSL methods (encrypt=2 and encrypt=3), are based on socat usage, http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html. The certs are not built the same way as the certs created by MySQL (for encryption of client communication with MySQL). To simplify SSL configuration and usage, we added a new encryption method (encrypt=4) so that the SSL files generated by MySQL can now be used for SSL encryption of SST traffic.
For instructions on how to create these files, see https://www.percona.com/doc/percona-xtradb-cluster/LATEST/howtos/encrypt-traffic.html.
Configuration
In general, galera views the cluster as homogeneous, so it expects that all nodes are identically configured. This extends to the SSL configuration, so the preferred configuration is that all machines share the same certs/keys. The security implication is that possession of these certs/keys allows a machine to join the cluster and receive all of the data. So proper care must be taken to secure the SSL files.
The mode “encrypt=4” uses the same option names as MySQL, so it reads the SSL information from “ssl-ca”, “ssl-cert”, and “ssl-key” in the “[sst]” section of the configuration file.
Example my.cnf:
1 2 3 4 5 | [sst] encrypt=4 ssl-ca=/path/to/ca.pem ssl-cert=/path/to/server-cert.pem ssl-key=/path/to/server-key.pem |
All three options (ssl-ca, ssl-cert, and ssl-key) must be specified otherwise the SST will return an error.
ssl-ca
This is the location of the Certificate Authority (CA) file. Only servers that have certificates generated from this CA file will be allowed to connect if SSL is enabled.
ssl-cert
This is the location fo the Certificate file. This is the digital certificate that will be sent to the other side of the SSL connection. The remote server will then verify that this certificate was generated from the Certificate Authority file in use by the remote server.
ssl-key
This is the location of the private key for the certificate specified in ssl-cert.
What about performance ? it is increased with encrypt=4 ?
This feature, by itself, has no SST performance impact. All we have done here is to improve the SSL configuration. There have been some small changes made for SST performance and we are looking into more changes for a future release.