The Transport Layer Security (TLS) protocol is used to provide confidentiality and data integrity between two communicating applications. OceanBase Database extends the original TCP communication to support the SSL/TLS protocol, addressing the issue of communication encryption. Using encrypted transmission can reduce the risk of sensitive information leakage in the database. The encryption and decryption process of information using keys can effectively protect data security. Specifically, database encryption transmission can be implemented using the SSL or TLS protocol.
OceanBase Database can be divided into the following three basic parts from the product architecture.
The communication between the components is implemented using two protocols:
MySQL protocol: The communication between the driver layer and the data link layer, as well as between the data link layer and the DB layer, is implemented using the extended MySQL protocol. After communication encryption is enabled, encryption takes effect immediately, and all new MySQL connections use encrypted communication.
OB-RPC protocol: The communication between OBServer nodes and between OBServer nodes and components such as liboblog and ob_admin is implemented using the OBServer's own RPC protocol. Since the connections between internal nodes are long connections, after encryption is enabled, internal node communication still uses the original non-encrypted method. After the OceanBase cluster is restarted, internal node communication encryption will take effect.
The OBProxy at the data link layer, the OBServer, liboblog, and obadmin at the DB layer all support SSL/TLS encrypted communication. They rely on OpenSSL or third-party SSL libraries to provide secure encrypted transmission services for businesses.
OceanBase Database provides different SSL/TLS authentication mechanisms for each user. These mechanisms include:
- One-way SSL authentication: The client needs to load the server's CA certificate. The client verifies the server's certificate in one direction.
- Two-way X509 authentication: Both the server and client need to load the other's CA certificate, and they verify each other's certificates in two directions.
- Special two-way authentication (combinations):
- Authentication with specified encryption algorithms: Based on two-way X509 authentication, it also limits the SSL encryption algorithms.
- Authentication with specified issuer: Based on two-way X509 authentication, it also limits the issuer of the client's CA certificate.
- Authentication with specified SSL subject: Based on two-way X509 authentication, it also limits the subject of the client's CA certificate.
- TLS password-free authentication: If the client does not need to verify the identity of the OBServer, it does not need to load the CA certificate. Otherwise, it does.