Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
Description
Right now wsrep/gcomm communication between Galera nodes can either be unencrypted, or it can be SSL/TLS encrypted.
There is no way yet to have a node accept both, even not just temporarily, so changing an unencrypted cluster to using encryption is not possible by doing a rolling restart, a node restarted after activating encryption in its wsrep_provider_options settings would no longer be able to communicate with the other nodes in the cluster that don't use encryption yet.
So right now making a cluster more secure by enabling encryption between the Galera nodes is only possible by shutting down the cluster completely, changing the wsrep encryption settings, and then bringing all nodes up again, with the cluster being completely offline / unavailable for at least a short period of time.
Attachments
Issue Links
- includes
-
MDEV-21730 Improve TLS/SSL error reporting
-
- Closed
-
The new Galera 4.8 replication library should fix this issue, from the release notes:
"In Galera replication library 4.8 we have made many new fixes and features; for one we incorporate the IST recovery and correct position as per 3.33 above. We have also added support for X509 certificate chains, changed the SSL error messaging (to become more human readable and friendly), plus we have also added socket.ssl_reload=1 and socket.dynamic=1 as options to reload the SSL provider certificate and the latter makes the upgrade path from non-SSL to SSL clusters much easier as nodes can communicate over both SSL and TCP connections"
socket.dynamic variable documentation in galera site says:
https://galeracluster.com/library/documentation/galera-parameters.html#socket-dynamic
As complete fix, this MDEV needs also mtr test for verifying the correctness. The mtr test (galera_3nodes.galera_dynamic_protocol) is under works atm, but no pull request for that yet.