I wanted to bring to your attention a potential issue I’ve encountered during testing. It appears that Redis is accepting connections even when an incorrect encoded password is provided in the configuration. To ensure proper setup, I followed the Broadcom documentation for Redis configuration and password encoding.
Here are the details:
We tested with an intentionally incorrect password in encoded format.
Despite this, the application was still able to connect to the Redis instance.
This was observed in standalone configurations.
Could you please help investigate this issue or advise if any additional Redis or client-side settings need to be enforced to prevent such behavior?
11.1.1
Gateway 11.1.2 supports configuring SSL to standalone client: see sample in https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/11-1/install-configure-upgrade/connect-to-an-external-redis-datastore/configure-redis-client-with-a-single-yaml-file.html#:~:text=This-,single%20yaml,-file%20shall%20allow
-For Redis in AWS Elasticache, enable AUTH by specifying the token and enable SSL (transit-encryption-enabled) https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/auth.html as that is a requirement for using AUTH.
you need to have your cluster password working correctly and then by using the below command the connection to redis from 11.1.2 should work .
echo -n "redispass" | openssl enc -e -aes-256-cbc -pbkdf2 -iter 600000 -saltlen 16 -pass pass:'********************' -a; history -d $(history 1)
U2FsdGVkX19xanadtmv6zs2YTJl2pG9uXOou0IGoZ/qX2eDB0cl66Q==
Decryption: echo "U2FsdGVkX1+17PxZQMFI6hWLcl5GcJ3Wt7Yuc5GmUP60kRLlIiJptQ==" | openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 -saltlen 16 -pass pass:'************************' -a; history -d $(history 1)
redispass%