"tls-cluster" is a setting that enables encryption of cluster bus traffic. However, this setting is also used to determine what port to return to clients when requested via CLUSTER NODES/SLOTS/SHARDS:
Therefore, if you try to start a cluster with a TLS port, none of your clients (even those connecting over the TLS port) will see this port in the cluster topology unless you enable "tls-cluster". It should be possible to start a cluster with a TLS port that does not encrypt the cluster bus traffic and have cluster clients use the TLS port.
Is there a reason that we need to use the "tls-cluster" setting in these cases? Can we simply return the TLS port to TLS clients, and the plaintext port to the remainder?
To reproduce
Create a folder, and populate it with a "key.pem" and "cert.pem" for TLS. CD to the folder and start three Redis servers locally, example:
docker run -d --name redis-server-1 --mount type=bind,source="$(pwd)",target=/etc/certs --network host redis:latest redis-server --cluster-enabled yes --tls-cluster no --tls-port 7379 --port 6379 --tls-cert-file /etc/certs/cert.pem --tls-key-file /etc/certs/key.pem --tls-replication no --tls-auth-clients no
docker run -d --name redis-server-2 --mount type=bind,source="$(pwd)",target=/etc/certs --network host redis:latest redis-server --cluster-enabled yes --tls-cluster no --tls-port 7380 --port 6380 --tls-cert-file /etc/certs/cert.pem --tls-key-file /etc/certs/key.pem --tls-replication no --tls-auth-clients no
docker run -d --name redis-server-3 --mount type=bind,source="$(pwd)",target=/etc/certs --network host redis:latest redis-server --cluster-enabled yes --tls-cluster no --tls-port 7381 --port 6381 --tls-cert-file /etc/certs/cert.pem --tls-key-file /etc/certs/key.pem --tls-replication no --tls-auth-clients no
````
Form the cluster:
redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 --cluster-replicas 0 --verbose
Connect using OpenSSL and see that it will only return the non-TLS port (6379) when queried via CLUSTER NODES/SLOTS/SHARDS:
openssl s_client --host 127.0.0.1 --port 7379
Example output:
$334 ea81846a5f475e7cad3db957a8d13e638bbf272c 127.0.0.1:6379@16379 myself,master - 0 1680626952000 1 connected 0-5460 bc9d02810d70a49136c6495fdfacd5725e2a84f5 127.0.0.1:6381@16381 master - 0 1680626955908 3 connected 10923-16383 acf3635f5d67512dd25872f6109d920096560dde 127.0.0.1:6380@16380 master - 0 1680626955000 2 connected 5461-10922
**Feature Request**
When a TLS client asks for the cluster topology, it should return the cluster topology with TLS ports, regardless of whether the cluster bus is encrypted.
**Comment From: hwware**
Could you please tell me which version you are working on? I will try to reproduce this issue on latest version and give you feedback ASAP. Thanks
**Comment From: murphyjacob4**
I used Redis 7.0.10, specifically [this](https://hub.docker.com/layers/library/redis/latest/images/sha256-94a25c195c764f7962087eda247471989797001c222f079d5d4dbb1c34cc4854?context=explore) docker image.
**Comment From: hwware**
Hi,
Thank you for the information!
On triaging the issue observed that, if tls-cluster is set no explicitly then there will not be any effect on cluster-announce-tls-port that is no effect on tls-port.
Here is the documentation link: [Documentation](https://redis.io/docs/management/config-file/ )
Here is the snippet from the documentation:
If tls-cluster is set to yes and cluster-announce-tls-port is omitted or set
to zero, then cluster-announce-port refers to the TLS port. Note also that
cluster-announce-tls-port has no effect if tls-cluster is set to no.
#################### CLUSTER DOCKER/NAT support
In certain deployments, Redis Cluster nodes address discovery fails, because
addresses are NAT-ted or because ports are forwarded (the typical case is
Docker and other containers).
In order to make Redis Cluster working in such environments, a static
configuration where each node knows its public address is needed. The
following four options are used for this scope, and are:
* cluster-announce-ip
* cluster-announce-port
* cluster-announce-tls-port
* cluster-announce-bus-port
Each instructs the node about its address, client ports (for connections
without and with TLS) and cluster message bus port. The information is then
published in the header of the bus packets so that other nodes will be able to
correctly map the address of the node publishing the information.
If tls-cluster is set to yes and cluster-announce-tls-port is omitted or set
to zero, then cluster-announce-port refers to the TLS port. Note also that
cluster-announce-tls-port has no effect if tls-cluster is set to no.
If the above options are not used, the normal Redis Cluster auto-detection
will be used instead.
Note that when remapped, the bus port may not be at the fixed offset of
clients port + 10000, so you can specify any port and bus-port depending
on how they get remapped. If the bus-port is not set, a fixed offset of
10000 will be used as usual.
Example:
cluster-announce-ip 10.1.1.5
cluster-announce-tls-port 6379
cluster-announce-port 0
cluster-announce-bus-port 6380
```
Hence, this looks to be expected.
Comment From: murphyjacob4
Thanks for taking some time to look into it.
I think you are correct that the usage of tls-cluster to determine whether to present the TLS or non-TLS port to customers was intentional, however this decision has made it impossible to use TLS when tls-cluster is disabled. This overload isn't intuitive and is preventing deployments which would like to disable cluster bus encryption but enable encryption for data access impossible.
Perhaps labeling the issue as a BUG was a mistake and this should be a feature request.
Comment From: hwware
@oranagra @madolson Do you think this is a potential feature in our cluster design? Thanks
Comment From: madolson
I think we can solve this for CLUSTER SHARD and CLUSTER SLOTS, I don't think it's worth trying to solve for CLUSTER NODES though. We can start populating the pport field to be the other port. if tls-cluster is yes it's the TCP port, if tls-cluster is no it can be the TLS port if present. Cluster nodes is sort of forever broken, and I don't feel much about fixing it.
Comment From: CharlesChen888
This is not only a problem of some CLUSTER commands. If "tls-cluster" is set to "no", the cluster won't be able to provide TLS service to clients, as any MOVED or ASK error does not contain the TLS port of the target node.
I think this is a design flaw in the routing table (cluster topology), as I stated in #12143.