目录
一、先分清：HTTPS 能干什么、不能干什么
HTTPS 核心作用（传输层安全）
HTTPS 解决不了的 3 个核心痛点（这就是必须加签名的原因）
二、签名机制的核心能力（业务层安全）
1. 身份鉴权：确认调用方合法
2. 全链路防篡改（不止网络）
3. 抵御重放攻击
4. 行为不可抵赖（对账、纠纷凭证）
三、极简对比总结
四、举一个真实支付攻击场景，直观理解
五、补充：HTTPS 和签名是互补，不是替代
一、先分清：HTTPS 能干什么、不能干什么
HTTPS 核心作用（传输层安全）
HTTPS 解决不了的 3 个核心痛点（这就是必须加签名的原因）
无法证明「请求参数是业务方真实发起」 HTTPS 只保证通道安全，不校验参数合法性、发送者身份。 举例：支付接口密钥泄露，攻击者拿到接口地址、参数，用自己设备发合法 HTTPS 请求，服务器无法区分是商户系统还是黑客发起。
无法防「重放攻击」 中间人完整截取一组合法 HTTPS 请求（下单 1 元），隔几分钟、几小时重复发送。 HTTPS 不会拦截重复请求，服务器会重复扣款；签名配合随机串 nonce + 时间戳才能杜绝重放。
服务端内部链路无校验 HTTPS 只保护外网传输链路。 请求到达支付网关后，网关会转发给订单、账户、账务微服务，内网是 HTTP / 内网 RPC，内网不存在 HTTPS 加密防篡改。 内网流转时参数被篡改（如金额 1 改成 9999），HTTPS 完全管不到，只能靠签名校验原始参数未被改动。
二、签名机制的核心能力（业务层安全）
签名是基于双方约定密钥 / 公私钥对全部业务参数做摘要加密，解决业务层面信任问题：
1. 身份鉴权：确认调用方合法
- 对称签名（MD5+AppSecret、HMAC-SHA256）：只有持有商户密钥的一方，才能算出正确 sign；
- 非对称 RSA/ECDSA 签名：商户用私钥签名，支付平台用商户公钥验签，彻底杜绝密钥泄露冒充。 HTTPS 证书只能证明域名，不能证明调用者是合法商户。
2. 全链路防篡改（不止网络）
签名是把所有业务参数（订单号、金额、用户、时间） 拼接后计算摘要： 只要任意一个参数被修改（金额、商品 ID），验签一定失败，直接拒绝请求。 覆盖场景：外网抓包改参、内网微服务转发篡改、程序漏洞导致参数篡改，HTTPS 只能管外网传输，签名覆盖全链路。
3. 抵御重放攻击
签名规范强制携带两个字段参与签名计算：
- timestamp 时间戳：限制请求有效期（比如 5 分钟），过期直接拒绝；
- nonce 随机唯一串：同一时间内不允许重复随机串。 就算黑客复制完整 HTTPS 报文重复提交，时间过期 / 随机串重复都会验签失败，不会重复扣款。
4. 行为不可抵赖（对账、纠纷凭证）
RSA 非对称签名下：只有商户私钥能生成合法签名。 后续出现扣款纠纷时，支付平台留存的原始参数 + 签名，可以证明这笔支付请求是商户主动发起，商户无法否认，满足金融支付合规要求；HTTPS 没有任何不可抵赖凭证。
三、极简对比总结
| 防护范围 | 外网网络传输通道 | 全链路：客户端→网关→内网微服务 |
| 加密对象 | 整个 TCP 报文 | 业务请求参数 |
| 防篡改范围 | 传输中途数据包 | 任何环节修改业务参数 |
| 身份校验 | 校验服务端域名证书 | 校验调用商户身份 |
| 防重放 | 不支持 | 配合时间戳 / 随机串拦截重复请求 |
| 不可抵赖 | 无 | RSA 签名具备，金融合规必备 |
四、举一个真实支付攻击场景，直观理解
假设只有 HTTPS、无签名：
增加签名后： 请求携带 timestamp=1788888888&nonce=abc123 参与签名，5 分钟后时间戳过期，验签失败，直接拦截重复扣款。
再另一种攻击：中间人不抓包，直接伪造参数 amount=9999 发起 HTTPS 请求，没有正确 sign，支付网关验签失败，拒绝下单。
五、补充：HTTPS 和签名是互补，不是替代
- HTTPS 防止明文泄露，避免密钥、参数裸奔；
- 签名保证请求可信、参数未改、不可重复、不可抵赖； 支付、金融类接口标准安全方案：HTTPS 传输加密 + 业务参数签名验签 双保障，缺一不可。
