Redis Enterprise DBMS must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.
<VulnDiscussion>Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
To encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.
If configured, Redis Enterprise Software (RS) can use industry-standard encryption to protect the data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol, which is the more secure successor to SSL.
To enable TLS, the RS cluster nodes, the database, and client must be configured as detailed below.
Configuration of the RS nodes:
By default, each cluster node has a different set of self-signed certificates. These certificates can be replaced with another certificate, preferably a certificate issued by an intermediate certificate authority (CA).
Configuration of the database:
To encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.
Note: Once TLS encryption is enabled for the database endpoint, the database does not accept unsecured connections. TLS encryption can significantly impact database throughput and latency.
Adding TLS CA signed certificates to the proxy:
The proxy is responsible for terminating the TLS connection.
Server certificate and key are located on /etc/opt/redislabs:proxy_cert.pem - server certificate thatproxy_key.pem - server certificate key*any update on these requires a proxy restart
Enabling of TLS is done via "ssl authentication" field in the UI. It is a requirement to add a client-side certificate as a TLS connection is done via client certificate authentication (not just server-side authentication).
Installing CA signed certificates high-level steps:
1. Replace the RS server certificates and key on all nodes with the CA signed certificate and restart the proxy.
Note: A certificate for the databases' endpoint should be assigned for the same domain as the cluster name. For example, for a cluster with the name "redislabs.com" the certificate should be for "*.redislabs.com".
2. Add the TLS client certificates in the UI including CA certificates and any intermediate certificates by chaining the certificate into one file (use a cat command to chain the certificates).
3. On the client side, import and trust the CA and intermediate certificates (chain the CA certificate with intermediate as one file to use and import).
Client configuration:
To connect to a database configured with TLS encryption, either use one of the Redis clients that inherently support SSL encryption, or use any Redis client and create a secured tunnel between the client machine and the RS nodes.
To create a secure tunnel between the client machine and the RS nodes, use tools that enable this functionality, such as spiped or stunnel. An example of how to use stunnel is detailed below.
Note: For security reasons, RS supports only the TLS protocol. Therefore, make sure the Redis client or secured tunnel solution used supports TLS, preferably TLS v1.2.
When using self-signed certificates on the cluster nodes, make sure to copy these certificates to the client machines as well, thereby enabling the client to validate the cluster nodes.
When using a certificate issued by an intermediate certificate authority (CA) on the cluster nodes, make sure that the CA root certificate is installed on the client machines.
Example how to secure client connection with TLS using stunnel:
The instructions below explain how to use stunnel for setting up a secure tunnel between a client machine and the RS nodes when the client is running on Ubuntu, using the default RS nodes' self-signed certificates, and a self-signed certificate on the client machine.
1. Install stunnel version 5 or higher on the client machine. Older versions of stunnel do not support the TLS protocol.
2. Create a self-signed certificate on the client machine.
3. Generate a private key by running the following commands:
sudo su
openssl genrsa -out /etc/stunnel/keyclient.pem 4096
4. Generate a client certificate by running the following commands:
openssl req -new -x509 -key /etc/stunnel/keyclient.pem
-out
/etc/stunnel/cert.pem -days 1826
5. When prompted, enter the appropriate configuration details for the certificate.
6. Copy the RS node certificates from all nodes to the client machine. The certificates are saved in a file named proxy_cert.pem, which is stored in /etc/opt/redislabs in each node.
7. Rename the certificate files fetched from the RS nodes as certsvr.pem. For example: certsvr1.pem, certsvr2.pem.
8. Create a single file for all of the server certificates on the client machine, by running the following command from the OS CLI. For example:
cat /etc/stunnel/certsvr1.pem /etc/stunnel/certsvr2.pem > /etc/stunnel/servercerts.pem
9. Configure stunnel for the connection to RS by using the steps below:
10. Create a redislabs.conf file in /etc/stunnel folder.
11. Make sure the certificates that have been generated exist in the following folder: /etc/stunnel.
12. Edit the redislabs.conf content to look as follows:
cert = /etc/stunnel/cert.pem key = /etc/stunnel/keyclient.pem cafile = /etc/stunnel/servercerts.pem verify = 2 delay = yes output = /tmp/stunnel.log pid = /tmp/stunnel.pid[redislabs] client = yes accept = [server IP address]:[configured port] connect = [database endpoint value]
Where [database endpoint value] is the database endpoint as can be retrieved from RS.
Note: The value for the accept parameter is the local IP and port that is used for redirecting the traffic through the secure tunnel to the database endpoint configured in the connect parameter.
13. Copy the contents of the client certificate from cert.pem and enter them in the SSL Client Authentication field, in the RS UI, of the database to be secured. When done, be sure to save the change.
14. Start the stunnel service by running the following command: service stunnel restart
Note: Any change made to the stunnel configuration requires restarting the stunnel service.
15. Check the stunnel log file to verify that the connection is working properly. The log file is created under the root folder within the configuration mentioned above.
16. Test the connection to the Redis database from the client machine. Use Redis-cli to run commands on the client machine, and the commands are redirected from the local machine's port [configured port] to the RS database endpoint. Note the connection to the Redis database is done through the local port; do not try to connect directly to the database endpoint.
TLS version information:
To set the minimum TLS version that can be used for encrypting the data in transit between a Redis client and a Redis Enterprise cluster, use the REST API or the following rladmin command:
rladmin> cluster config min_data_TLS_version [version, e.g., 1.2]
Note that if a client supports an older TLS version, the communication is not allowed.