WL#12990: Group Replication: TLS 1.3 support
Affects: Server-8.0 — Status: Complete
EXECUTIVE SUMMARY ============================== WL#12361: "Support TLS 1.3 in the server and libmysql" implemented support of TLS 1.3 on the server which did not consider Group Replication, in particular GCS. The outcome is that when the server is configured to only use TLS 1.3, then Group Replication will not start throwing a error saying that it does not support TLS 1.3. USER/DEV STORIES ============================== As a MySQL DBA, i want to be able secure communication using TLS 1.3 among all group members in order to use the latest and greatest security features available. SCOPE ============================== This worklog will implement TLS 1.3 support on GCS/XCom. LIMITS ============================== N/A
FR-1: It must be possible to use TLS 1.3 in XCom links FR-2: It must be possible to join a node that does not have this feature implemented to a group that has this feature implemented FR-3: It must be possible to join a node that has this feature implemented to a group that does not have this feature implemented. All other requirements must respect FRs and NFRs from WL#12361.
SUMMARY OF THE APPROACH ===================================== With the advent of TLS 1.3, which is backwards-incompatible with other protocol versions, there was the need to add extra variables and fields to MySQL in order to configure it. Since GCS/XCom maintain their own communication layer, one needs to pass those new configuration parameters to the GCS/XCom layer. The bulk of the work is to use the new parameter tls_ciphersuites inside XCom, adding a new configurable parameter on GCS interface. SECURITY CONTEXT ====================================== This WL will augment GCS/XCom to use TLS 1.3, hence reducing possible attacks. UPGRADE/DOWNGRADE and CROSS-VERSION REPLICATION ====================================== This WL is affected and it must be tested for Upgrade/Downgrade. In generic terms, OpenSSL is able to negotiate a connection to make sure that it uses the most secure protocol configured by the user, if everyone configures all available protocols. Trouble arises when a user configures a specific protocol, or ciphers that are not supported by the available protocols. UPGRADE ====================================== If a node wants to join a group that only speaks, at maximum, TLS 1.2, which is the previous supported version, it must enter the group making sure that it has protocols under 1.3 supported and configured. OpenSSL will take care of the negotiation and make sure that everyone speaks the best protocol available. When this is done, the whole group will communicate using the best protocol available. This means that, if a DBA configures the new node to *ONLY* use TLS 1.3, it won't be able to enter an old group. In order to make sure that everyone is using TLS 1.3, if configured, one needs to make a group rolling restart. Then, all members will now start using TLS 1.3 DOWNGRADE ===================================== If an old node wants to join a group that speaks at maximum, TLS 1.3, one needs to make sure that the group is configured with previous versions of the TLS protocol. As in the Upgrade section, if the group only speaks TLS 1.3, old nodes won't be able to join it. If the group is configured in a traditional way, meaning that it supports TLS versions under 1.3 starting at TLS 1.0, an old node can join without any issue. If the group is configured to only speak TLS 1.3, one needs to configure any necessary previous version of the protocol compatible with the node that we want to add and execute a rolling restart of the group. USER INTERFACE =================================== Implementing TLS v1.3 brought a new configuration item to MySQL: https://dev.mysql.com/doc/refman/8.0/en/server-system- variables.html#sysvar_tls_ciphersuites. This can now be configured and it has meaning in Group Replication. OBSERVABILITY =================================== N/A DEPLOYMENT and INSTALLATION =================================== N/A PROTOCOL =================================== We will now support TLS 1.3 with all the implications that are already described in the Upgrade/Downgrade section. FAILURE MODEL SPECIFICATION =================================== N/A
BLOCK DIAGRAM ===================================== N/A INTERFACE SPECIFICATION ===================================== A new parameter must be passed to GCS in order to configure the new TLS Cipheruites for TLS 1.3. As such, GR must now do the following: gcs_module_parameters.add_parameter("tls_ciphersuites", <
>) < > must be extracted from the system variable "tls_ciphersuites" DESIGN IMPLEMENTATION STEPS ===================================== The goal of this WL is to add full support for TLS 1.3. This means that: - We must accept TLS 1.3 as protocol; - Configure the new tls_ciphersuites parameter for establishing a connection. The implementation is heavily based in WL#12361. Accepting TLS 1.3 is out-of-the-box, because it is just another value in tls_version sysvar. It is transparent to us. In order to configure the new tls_ciphersuites parameter for establishing a connection, one needs to pass it to XCom, via GCS. It will get its value from the new sysvar "tls_ciphersuites". We need to modify: - gcs_xcom_interface.cc in order to receive the new parameter in "configure_xcom" - gcs_xcom_proxy.cc -- xcom_set_ssl_parameters() to receive the new parameter -- xcom_init_ssl() to call XCom's xcom_init_ssl with the new parameters - xcom_ssl_transport.* to accept, configure and support TLS 1.3 and the new parameter Note that, in order to support our smoke tests, one must change the input parameters of xcom_set_ssl_parameters to a struct, because they exceed the maximum allowed number of parameters of GMock.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.