RabbitMQ消息需额外签名，因其仅为传输通道而非可信边界；即使启用TLS和vhost权限，攻击者突破上游服务后仍可注入恶意消息，签名是唯一能确认消息源自可信服务端的手段。
PHP 本身不直接参与 RabbitMQ 消息的签名验证——RabbitMQ 协议层不提供内置签名机制，所有签名必须由业务层在投递前生成、消费前校验。你不能依赖 php-amqplib 自动做这件事，必须自己控制签名原文构造、密钥管理与验签时机。
为什么 RabbitMQ 消息需要额外签名？
RabbitMQ 是传输通道，不是可信边界。即使启用了 TLS 加密和 vhost 权限隔离，攻击者若突破上游服务（如伪造支付回调、绕过网关直接发消息），仍可向队列注入恶意 payload。签名是唯一能确认「该消息确实来自你信任的服务端」的手段。
- 不签名 → 攻击者用
curl直连 RabbitMQ HTTP API 或伪造 AMQP 客户端发消息，触发下游业务逻辑 - 只靠 TLS/账号密码 → 只防窃听和未授权连接，不防合法账号下的恶意消息
- 签名必须绑定业务上下文：比如
order_id、amount、timestamp，不能只签一个固定字符串
如何构造可验证的签名原文？
签名原文必须满足「可重现性」和「抗篡改性」：消费者拿到消息后，用相同规则拼出完全一致的字符串，才能验签成功。常见错误是忽略字段顺序、空值处理、编码差异。
- 原始消息体必须是 JSON 字符串（非 PHP 数组），且使用
JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES编码，避免中文被转义破坏一致性 - 签名原文 =
HTTP_METHOD（固定为POST） +queue_name+json_encode($body, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)+$timestamp（毫秒级） - 必须把
$timestamp同时写入消息 body 和签名原文——否则无法校验时效性；建议限制窗口为 5 分钟，过期丢弃 - 不要用
http_build_query()处理 body，它会打乱 key 顺序、过滤空值、自动 urlencode，导致服务端和消费者拼出的字符串不一致
PHP 消费端怎么安全验签？
验签必须在反序列化之后、业务逻辑之前完成，且密钥绝不能硬编码或从环境变量明文读取（应通过 Vault 或加密配置中心获取）。推荐用 hash_hmac('sha256', $sign_string, $secret, true) 生成二进制签名，再 base64_encode() 传输。
立即学习“PHP免费学习笔记（深入）”；
- 从消息 header 中读取
delivery_info['headers']['X-Signature']和X-Timestamp，拒绝缺失任一 header 的消息 - 检查
X-Timestamp是否在当前时间 ±300 秒内，超时直接reject并requeue=false - 用和生产端完全相同的规则重建
$sign_string，注意 JSON 编码选项、字段顺序、空格 - 用
hash_equals()对比签名（防止时序攻击），别用=== - 如果验签失败，记录完整消息体 + headers 到审计日志，但不要打印
$secret—— 这是关键红线
AMQP 连接本身的安全配置要点
签名解决的是「消息内容可信」问题，而 AMQP 连接安全解决的是「传输过程不被窃听/劫持」问题。两者缺一不可。
- 强制启用 TLS：在
php-amqplib连接参数中设置'use_ssl' => true，并指定'cafile'、'certfile'、'keyfile'路径 - 禁用弱协议：RabbitMQ 服务端需关闭 TLSv1.0/TLSv1.1，在
/etc/rabbitmq/rabbitmq.conf中配置ssl_options.tls_versions.1 = tlsv1.2 - 不要复用 Web 服务的证书：AMQP 通信应使用独立域名（如
amqp.example.com）和专用证书 - 消费者进程启动时，先验证书链有效性（可用
openssl verify -CAfile ca.pem cert.pem），失败则退出，不尝试连接
最易被忽略的一点：签名密钥轮换时，消费者必须支持双密钥并行验签（旧密钥用于处理积压消息，新密钥用于新消息），且轮换窗口期间不能停服。这要求签名逻辑封装成可插拔组件，而不是散落在 consume() 方法里硬写。
