Redis Pub/Sub本身不提供消息加解密能力，所有消息明文传输；TLS仅保护链路安全，AUTH仅控制连接鉴权，无法防止有权限客户端读取频道内明文消息，加解密必须在应用层实现。
Redis 的发布订阅（Pub/Sub）本身不提供任何加解密能力，所有消息以明文形式在网络和内存中传输。如果你需要安全的消息传输，必须在应用层自行实现加解密逻辑——这不是配置开关，而是代码责任。
为什么不能依赖 Redis 自带的 TLS 或 AUTH 实现消息加密
Redis 6.0+ 支持 TLS 加密通信（tls-cert-file、tls-key-file），但这只保护客户端与 Redis 服务器之间的传输链路（即防窃听），不防止 Redis 进程内消息被其他有权限访问 Redis 的客户端读取；AUTH 仅控制连接鉴权，对频道内消息内容零保护。一旦攻击者拿到 Redis 的读权限（比如通过配置泄露或弱密码），PUBSUB CHANNELS 和 SUBSCRIBE 就能直接看到所有明文消息。
加解密必须放在业务代码里，不是 Redis 配置里
典型做法是在发布前加密 payload、订阅后解密 message。关键点如下：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 加密算法选
AES/GCM/NoPadding（推荐）或AES/CBC/PKCS5Padding，避免使用 ECB 模式 - 密钥不能硬编码，应从环境变量或密钥管理服务（如 HashiCorp Vault）加载
- 每次加密必须用唯一 IV（初始化向量），IV 可随密文一起 Base64 编码后拼接发送，例如：
base64(iv)+":"+base64(ciphertext) - 订阅端收到
onMessage(String channel, String message)后，先按约定格式拆分 IV 和密文，再解密 - 如果使用 JSON 传输，建议整个 JSON 字符串加密，而不是只加密某个字段——否则字段名、结构仍暴露
Spring Boot 中加解密的典型陷阱
很多人在 RedisMessageListenerContainer 或 @EventListener 回调里做解密，但容易忽略以下问题：
- 解密失败时未记录原始密文和错误堆栈，导致排查困难 —— 建议在 catch 块中记录
Base64.getEncoder().encodeToString(rawBytes) - 未校验消息来源合法性，攻击者可伪造频道名并发送垃圾密文触发解密异常 —— 应在解密前检查
channel是否在白名单内（如只接受secure:order:notify） - 用
StringRedisTemplate发送时默认序列化为 UTF-8 字符串，若密文含不可见字符（如 \u0000），可能被截断 —— 改用RedisTemplate<byte byte></byte>直传字节数组 - 未设置合理的超时和重试：解密耗时波动大时，可能拖慢整个监听线程池，建议把解密逻辑移入异步线程处理
最常被跳过的一步是密钥轮换设计。上线初期用固定密钥很常见，但一旦密钥泄露，所有历史密文都可被批量解密。真正安全的做法是让每条消息携带密钥版本号（如 {"kver":"v2","data":"..."}），配合密钥管理服务动态获取对应密钥——这已经超出 Redis Pub/Sub 范畴，属于完整密钥生命周期管理了。
