Redis TLS today only checks that a peer certificate chains to the configured CA (and is not expired). It does not check that the certificate belongs to the peer you intend to talk to. That is fine with a dedicated per-cluster CA, but under a shared/organizational/public CA any holder of a CA-signed cert can impersonate a master or cluster peer: on replication a MITM can capture master AUTH credentials; on the cluster bus (no per-message auth—sender is only the public node ID in the header) an impostor can open an inbound bus connection and forge messages (e.g. FAIL).
Add an opt-in configuration (default unset = today’s behavior) that, when set, additionally requires the peer certificate to present one of a locally configured expected name(s) in SAN (CN only as fallback), verified as part of chain validation. The expected name must come only from local configuration—never from the dialed address or anything received over the wire.
Requirements:
- Enforce on outbound server-to-server TLS: replication, cluster bus, and MIGRATE (including the blocking connect path).
- Enforce on inbound cluster-bus accepts (client cert of the connecting peer), so impersonation is blocked even when the victim never dials the attacker.
- Do not change ordinary client/data-port TLS identity (AUTH/ACL remain responsible there).
- Support a space-separated list of names (match any); reject whitespace-only values and non-space whitespace in names at config time; empty value clears/disables.
- Keep mutual TLS on the cluster bus as today; this is a refinement on top of existing CA verification when the option is set and a peer cert is presented.
- Peer-name checking needs OpenSSL’s host-verify machinery (OpenSSL ≥ 1.0.2). Building TLS against older OpenSSL should fail clearly by default, with a documented compile-time opt-out that warns and skips the name check (CA check still applies) when the option is set.
- Document the trust model and the operational requirement that the identity SAN must be on the cert used in both server and client roles for cluster/replication.
- Extend the TLS test cert generator with a cert that carries shared cluster SANs, and cover matching/mismatching names, multi-name lists, runtime CONFIG SET, MIGRATE enforcement, config validation, cluster formation with the check on, and rejection of a forged bus FAIL from a CA-signed cert lacking the expected identity.
Interface contract — the change must expose exactly this surface:
CONFIG option name: tls-expected-peer-name (string; empty clears; CONFIG SET-able). Compile-time opt-out macro: TLS_NO_PEER_NAME_VERIFICATION. Test helper certs: tests/tls/san.{crt,key} with SAN DNS redis.local and cluster.local (via utils/gen-test-certs.sh).
Work only inside this repository checkout. Make the code change the task
describes, keeping the diff focused — no drive-by refactors.
When you are done, leave your changes committed or in the working tree;
they are collected automatically.
Stay on this snapshot checkout (`task/ycb_redis_c58d0fb9c62e8`). Never checkout, pull, or rebase onto `main`. That branch is a README-only orphan.
Stay on this HEAD. Do not fetch another default branch. Push only on the Cursor-created `crazy-cursor/…` side branch from this HEAD.
Some past runs of this task were launched with a different prompt (the prompt template changed since, or those runs predate this benchmark's stored prompt). Each run persists the exact prompt it sent at launch — that per-launch record is the audit trail; this page shows only the current one.
Reference diff
The task commit's diff against its first parent — the judge's comparison target.