Network Encryption
Previous to the release of NuoDB 4.0, NuoDB used Secure Remote Password (SRP), as defined in RFC 2945, for authentication and key exchange for all network protocols including those between Storage Managers (SMs) and Transaction Engines (TEs), between clients and TEs, between (nuoagent) admin services and SMs and TEs, and between (nuoagent) admin services themselves. When authentication is successful, further communication is encrypted using a cipher; this cipher is automatically negotiated when the network connection is created.
When using NuoDB Admin for database and domain management, the default network encryption is TLS. NuoDB Admin services (nuoadmin) do not use SRP. By default, communications are encrypted using TLS for admin-to-admin communications. Furthermore, the admin-to-engine (either an SM or a TE) and engine-to-engine connections are secured using TLS 1.2.
|
Negotiation of protocols and ciphers occurs individually for each network connection created. Therefore, some clients may be communicating with one protocol while others may be using another. The same is true for individual SMs or TEs. Since every SM and every TE requires a network connection to every other SM and TE, it’s not possible for a new SM or a new TE to join the database unless it has at least one network protocol in common with every SM and TE already present in the database.
Selecting TLS or SRP
Although NuoDB 4.0 supports both SRP and TLS, all NuoDB engines (SMs and TEs) will prefer TLS (if available. If the TLS connection should fail, the engine falls back to SRP. To turn off SRP fallback, set the cipher-suites database option to TLS. For more information on using cipher-suites, see Database Options.
Supported Cipher Suites
NuoDB engines (SMs and TEs) use OpenSSL v1.1.1b. For the list of supported cipher suites, see OpenSSL documentation.
Cipher suites available to NuoDB Admin Processes (APs) are determined by the Java environment that is being used. NuoDB only supports TLS 1.2 or above.
Specifying Available Database Cipher Suites
NuoDB 4.0 does not support cipher suite selection. All OpenSSL cipher suites are available
Using TLS in NuoDB Drivers
TLS is supported by NuoDB’s C, C++, JDBC, and Python drivers.
For information on enabling TLS in NuoDB’s C and C++ driver, see Using TLS in the C++ Driver.
For information on enabling TLS in NuoDB’s JDBC driver, see Using TLS in the JDBC Driver.
For information on enabling TLS in NuoDB’s Python driver, see https://github.com/nuodb/nuodb-python.
Supported Ciphers
NuoDB SRP supports the following ciphers:
| Name | Description |
|---|---|
|
AES-256 cipher in CTR mode. This is a strong cipher using a 256-bit key. |
|
This cipher is not considered secure. Where possible, this cipher should not be used. |
|
No encryption is used at all. This should only be used if the entire network is protected through other means. |
| Cipher names are case-sensitive and must be used exactly as seen in the table above. |
The default list of ciphers is AES-256-CTR,RC4. The database does not allow the None cipher by default: it must be explicitly added to the list before it can be used
|
Although the RC4 cipher is not considered secure, it is provided for backwards compatibility as older releases of NuoDB supported only this cipher. If you do not need backwards compatibility, you can override the default list of ciphers to remove the RC4 cipher.
Specifying Available Database Ciphers
NuoDB supports the following database options for overriding the default list of ciphers:
-
enabled-ciphers- a comma-separated list of ciphers that the database accepts from clients (both SQL clients and admin clients). -
peer-ciphers- a comma-separated list of ciphers that the database accepts from other SMs and TEs, and from admin services.
| The comma-separated lists of ciphers referred to here are ordered by most preferable to least preferable. The most preferable cipher to the server that is also supported by the client is the cipher chosen. |
For more information on using these options, see Database Options.
Specifying Available Client Ciphers
The NuoDB clients provided with the NuoDB package (C and C++ drivers) support the same ciphers as supported for the TEs. The latest JDBC driver also supports all ciphers described in Supported Ciphers. For other NuoDB Drivers, see the documentation for that driver (links to relevant documentation available here).
All drivers support at least the RC4 cipher.
|
To specify which ciphers the client accepts during negotiation, configure the ciphers connection property to contain a comma-separated list of ciphers. For more information, see Connection Properties.
Encrypting Communication Between Database Processes
Each database processes is started with a private key and certificate that is used as its identity, plus a set of trusted certificates. These are all passed as base64-encoded strings via standard input to the database processes, so that it is impossible for an attacker to intercept it, unless they compromise the nuodb binary itself. The set of trusted certificates is used to verify the AP that the database process connects to and also all other database processes. Database processes form a mesh-network with each other and maintain a connection to an AP. All of these connections are secured using TLS 2-way/mutual authentication (authentication happens as part of the TLS handshake).
A database process can be started directly by the AP that is managing it (in a physical/VM deployment or in a separate container).
If the database process is started in a separate container, then the container must have a client key exposed into it that is used to communicate with the admin layer over HTTPS/TLS (also mutually-authenticated). If the AP has a certificate with BasicConstraint:CA=true, then that means the AP can act as a Certificate Authority and sign certificates. In this case, the entry-point script that runs inside the container generates a new key pair for the database process to be started and sends a start-process request to the admin layer over HTTPS, which includes a Certificate Signing Request for the newly-generated public key. NuoDB Admin will sign the certificate and return it to the HTTPS client, which then invokes the nuodb binary and sends the private key (which was generated locally and was never transmitting over the network), the NuoDB Admin-signed certificate, and the set of trusted certificates (also supplied by the admin layer) to the database process over standard input.
Communication Between Database Processes in Containerized Deployments of NuoDB
If the AP is not configured with a certificate that has BasicConstraint:CA=true, then it cannot sign certificates.
In this case, a containerized database process would have to have an existing PKCS12 keystore exposed into it that contains the key pair and certificate for the database process (NuoDB Admin still supplies the set of trusted certificates).