Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNI support for Sentinel connections with TLS #1837

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

MSuter6
Copy link

@MSuter6 MSuter6 commented Nov 22, 2023

Currently, when connecting to Redis with Sentinel, the servername attribute required for the SNI (Server Name Indication) TLS extension is not updated. Therefore, in cases where the connection relies on SNI, connections will fail as SNI routing cannot be properly handled.
This issue is caused by the dynamic nature of Redis instances handled by Sentinel. Even though the servername attribute can be set on the tls object on connection, it would need to be set to the host of the current master instance which is unknown at the point of connection and can change in case of failover events. Therefore a solution which dynamically assigns the servername attribute according to the current master is necessary.

This PR adds a flag enableDynamicSNIForSentinelMode to SentinelConnectionOptions which dynamically sets the servername attribute on the Redis instance Sentinel has elected to connect to.

The flag only works in combination with enableTLSForSentinelMode and tls on the SentinelConnectionOptions object.

This PR addresses this issue.
The PR does not break existing behaviour and ensures backwards compatibility of the ioredis library. Appropriate tests and updates to the Readme are included.

…onnections which triggers dynamic assignment of the `servername` attribute (TLS SNI support) when connecting to Redis.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant