[kbinetruy]

A Redis server that only accepts TLS (a managed service, or tls-port with port 0) cannot be used today. This was asked on the mailing list in 2022: https://groups.google.com/g/rtpengine/c/gO2hWMKxCNA/m/DNH37Z54BQAJ

This PR depends on #2212, which depends on #2211. The branch has 13 commits; only the last two are new:

1. MT#55283 redis: optional TLS for the Redis connections (12 files, +550 −5)
2. MT#55283 redis: TLS for the Redis Sentinel connections (4 files, +87 −8)

The two commits on their own: kbinetruy/rtpengine@redis-sentinel...redis-tls

1. With --redis-cafile or --redis-capath, as for the MQTT options, every Redis connection uses TLS: --redis, --redis-write, --redis-subscribe, the restore copies, and the async connections. --redis-certfile and --redis-keyfile add a client certificate. One SSL_CTX is made at startup. The handshake follows the command timeout. On a reconnect it runs in the thread that makes the attempt, without r->lock. A refused certificate or a handshake timeout is a failed connect, logged with the reason.

Released hiredis (1.2.0 to 1.4.1) checks only the chain, so the name is checked here, in the subjectAltName only. An address needs an IP entry, and no SNI is sent. A host name is checked with X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, and sent as SNI. --redis-tls-server-name replaces the expected name of every data node.

2. The Sentinel thread uses the same context: a Sentinel's certificate must match its host as given in --redis-sentinel. The ROLE check of a master must match the address that the Sentinels gave, or --redis-tls-server-name.

Option	Default	Meaning
--redis-cafile=FILE, --redis-capath=PATH	unset	Either one turns TLS on for every Redis connection.
--redis-certfile=FILE, --redis-keyfile=FILE	unset	Client certificate. Both or neither.
--redis-tls-server-name=NAME	unset	Name expected from every data node (and sent as SNI).

TLS 1.2 is the minimum. Files are PEM, and password-protected keys are not supported, as for MQTT. utils/gen-common-flags defines HAVE_HIREDIS_SSL when pkg-config finds hiredis_ssl. On Debian trixie and Ubuntu noble, libhiredis-dev ships it. The TLS options exist only in a build with hiredis_ssl. On other builds (Debian bookworm) they are unknown command-line options, as the MQTT ones, and a redis-cafile key in the configuration file is ignored.

Lab. Everything runs over TLS, with Sentinel, repair and resync and client certificates: failover ×3 and frozen master ×3. Each run had 0 lost, 0 deleted back, and 156 calls restored by a takeover. A reconnect to the new master took 3.4–4.6 ms over TLS, against 4.3 ms over plain TCP.

Testing. t/auto-daemon-tests-redis-tls.pl (126 checks, about 7 s) runs fake Redis and fake Sentinels over IO::Socket::SSL, with certificates made by openssl at test time (libio-socket-ssl-perl added to Build-Depends). It covers every connection type, every refusal (another CA, another address or name, partial wildcard, CN only), SNI, a required client certificate, a silent peer and the startup checks. It fails on the parent commit, and catches mutants of the checks (one equivalent mutant survives). make asan-check on master 3865f896: exit 0 on Debian trixie and Ubuntu noble, 9666 ok, 0 not ok. The patches apply with git am on 3865f896.

Questions:

1. Should TLS be turned on by --redis-cafile (as for MQTT), or by an explicit --redis-tls switch?
2. Should the Sentinels share the data nodes' TLS options (as Redis configures both with the same tls-* directives), or have their own?

Lab method, per-run figures and test details: https://github.com/kbinetruy/rtpengine/blob/redis-notes/redis-sentinel-notes.md