Chiffrement en transit avec TLS

By default Redis speaks plaintext over the network. Anyone able to sniff the wire can read your commands, including AUTH passwords and cached data. TLS encrypts the connection so traffic stays confidential and tamper-evident.

TLS uses certificates:

• A server certificate proves the server's identity
• A private key the server keeps secret
• A CA certificate clients use to verify the server

For testing, the Redis source ships a helper script, or you can use openssl to create a CA and a server cert/key pair.

Configure the TLS port and certificate paths. Setting port 0 disables the plaintext port so only TLS is accepted.

For stronger security, require clients to present their own certificate (mTLS). The server then authenticates the client in addition to encrypting traffic.

redis-cli supports TLS with the --tls flag plus the CA and, for mTLS, the client cert and key.

Client libraries accept TLS settings: enable TLS, point to the CA, and (for mTLS) the client certificate and key.

Inter-node traffic should be encrypted too. Enable tls-replication yes and tls-cluster yes so replicas and cluster bus connections also use TLS.

Restrict allowed protocols and ciphers to modern, strong options to avoid downgrade attacks.

TLS protects data in transit, not at rest, and does not replace authentication. Keep using requirepass/ACLs and bind to trusted interfaces; TLS is one layer of defense in depth.

TLS adds CPU overhead for the handshake and encryption. It is usually negligible with persistent connections and connection pooling, but worth measuring under load.

You enabled TLS on Redis: generated certificates, configured the TLS port and key/cert files, optionally required client certs for mTLS, secured replication and cluster traffic, and connected from CLI and code. Remember TLS is one layer; pair it with authentication and network isolation.