API 接口已经有 HTTPS 的前提下，为什么还需要签名机制？

[dzdh]

注意场景：

• 服务端对服务端的接口，不是客户端对服务端的接口
• 防止中间人可以 PINNED Pub Key，因此中间人攻击不在考虑范围内
• 极端条件可以使用客户端证书

综合以上三点。为什么在 Https 的保护下，还要额外做签名验证？

主要疑问，如 stripe 的退款接口

curl https://api.stripe.com/v1/refunds -u "$密钥:" -d charge=$charge_id

就可以发起一笔订单的退款或者扣款。按照某些论述的话，没有签名的 Stripe 岂不是非常危险？

[dzdh]

@kejialiu #138

Paypal 、Stripe 没有客户端证书。因何安全？

**纯技术角度**

[no1xsyzy]

@dzdh SSL/TLS 对面可以手动关闭验证的，你不能保证对面不会犯蠢把验证关了，尤其关闭的选项还不复杂，置个 false 就成。
当然，都 ssl pinning 了，你对 Client 端似乎是有控制能力的？不过我都建议过“为了避免将来的自己犯蠢，不要在用户提交的格式化文本中使用 html （即使你能正确地使用白名单摆平一切）”…… 参考墨菲定律

存在一些实现或者 binding 中没包含客户端证书实现

遗留问题就是旧系统已经有签名了，习惯就是旧系统上搞了签名，新系统思维定势，就像明明有 prepare 了还搞一堆字符限制，明明 UTF-8 支持非常普遍且应当是默认，仍然有用 GBK 的人

上面一直在说重放，其实在恰当的使用下 SSL/TLS 已经可以避免中间人重放（两边都是每次需要产生新随机数，握手信息重放直接导致密钥不相等，但不过保持 TCP 链接重放就不清楚了，应当会被 CBR 防下来）
对了，有时会遇到没有根证书的情况，得自己想办法搞一个…… 我写 ponylang 的时候就发现 ponylang 的 SSL 库没法尝试从操作系统中获得证书信息，只能自己带了个 cacert.pem （但是将来也不太可能进行更新，是个隐患）
https://github.com/no1xsyzy/project-v2c/tree/master/v2c-pony

[dzdh]

@no1xsyzy #142

仍然不明。

可以关闭验证，他就可以公开泄露签名密钥。

这就已经不再是技术方案的问题了吧？

[3dwelcome]

@dzdh "我的$ukey 在公网传输，但是有 https 保证不被泄露啊？有什么问题吗？"
今天 V2 有个帖子，说的就是 chrome 现在版本的本地执行代码漏洞，光 JS 代码，就能成功调出用户电脑里的计算器程序。理论上 chrome 用户人数最多，版本更新最快，应该更安全，可事实却不是。

正所谓道高一尺，魔高一丈。

你说 https 保证$ukey 在未来不被泄露，这真不太好说。现在全民普及 SSL，大厂为了性能，会专门买那种 RSA 加速卡，设置一个专门网关来加速大批量 SSL 处理过程。一旦 SSL 经过了中间转手，一切都无法 100%保证了。

这种转手对于 SSL Pinning 是无感知的，因为和你交换证书的网关，背后有无数机器，不是一台单独 PC 。

[dzdh]

@3dwelcome #144

？？？ 加速只是『计算』 TLS 通道仍然是『绝对安全』的。到终端业务机器保证全链路 TLS 就依然安全。

不要说如何保证链路，就像不能保证用户不会泄露 KEY 一样。这不是技术方案问题了。

[ZeroClover]

@kejialiu https://support.cloudflare.com/hc/zh-cn/articles/360022014111-%E4%BA%86%E8%A7%A3-Keyless-SSL

各种什么私钥泄露问题只要一个 HSM 就可以解决问题，私钥只进不出，所有调用只在 HSM 能完成签名，然后将签名结果给服务器。除非你买的是带后门的 HSM，或者刚好撞上有设计缺陷的 HSM 。

如果本身运行环境就是不可信的，那需要的是整个系统做零信任设计，客户端放个签名无非就是浪费恶意攻击者几分钟而已。

[chizuo]

我觉得你说的有一个错误：

```
sign = sign(signString) #按照指定算法如 md5/shaX 等计算 hash 得到最终的『签名』
```

签名是拿自己私钥去签名啊，怎么会使用 hash ？用 hash 是做消息验证

[dzdh]

@3dwelcome #144

你对 HTTPS 所有可能或不可能碰到的问题，在『签名模式』下都有对应的风险。TLS 私钥泄露？那签名 KEY 也能泄露。算法破解？那 KEY 也能被破解。管理不善？那 KEY 也能管理不善。


chrome 漏洞？ 签名模式的客户端就没漏洞？
tls 算法漏洞？签名模式的 hash 算法没漏洞？
服务器环境不安全？签名模式服务器环境就安全？

难道就不做开发了吗？

[dzdh]

@chizuo #147

你说的签名是额外使用非对称加密算法生成的『签名』

我指的签名，就是我给出的代码的『所谓的签名』，早期的支付宝、微信 v2 版本支付接口、SNS 社交平台等等等的早期签名都是这种。

然而，即便是你说的非对称加密算法的签名，在 HTTPS 模式下为什么有存在的必要？

[3dwelcome]

@dzdh "？？？ 加速只是『计算』 TLS 通道仍然是『绝对安全』的。"
RSA 加速卡就是 TLS 解密用的，你只能保证服务器到服务器这段距离是安全的，不会被运营商插入什么奇怪东西。但没办法保证客户集团网关解密后的数据流，是绝对安全的。

这和你 API 设计机关算尽，却防不了内鬼同事是一个道理。

[dzdh]

@3dwelcome #150

论点到底是什么。

加速卡是吧？好，我当他 100%绝对的『不』安全我不用行不行。

请从『纯技术』角度证明：HTTPS 不行，必须要有签名模式辅助。

[3dwelcome]

@dzdh "论点到底是什么。"
写那么多，就是回复你的那句：“我的$ukey 在公网传输，有 https 保证不被泄露”

我结论就一句话: 不传最安全。

[dzdh]

@3dwelcome #152

上面无数次提到密钥本身安全和泄露规避风险和方法。

结论并不能成立。

[dzdh]

@3dwelcome #152

补充，请从『纯技术角度』来『『证明』』 HTTPS 不安全

[nikan999]

补充一下# 129 的内容，
端到端不仅仅是 公网到公网，还有内网到内网， 所以 https 只保证了公网不会出现问题， 数字签名保证了整个传输链路不会出现问题

[3dwelcome]

@dzdh “请从『纯技术角度』来『『证明』』 HTTPS 不安全”

上面提到过，SSL 的安全核心依赖的是 hmac 的 key，俗称 master secret 。如果你电脑里这个硬件内存地址被泄露了，那所有的包都是能成功解密的。

你可以确保自己的服务器万无一失，可客户服务器凭什么去保证不会被挂什么木马？

安全从来就是相对而言的打分制，支付 API 加上 url 签名，哪怕只能提升一点点安全系数，那也是值得的。

[chinvo]

你可以用 oauth client credentials grant 给客户端发 token, 然后用这个 token 取代直接发送 apikey 的方式.

这样可以减少被中间人导致 apikey 泄露的风险.

与固定且不易更换的 apikey 比起来, 可以随时吊销的短期有效的 token 更安全.

用签名而不是直接发送 apikey 也有这方面的考虑 (避免 apikey 在传输过程中意外泄漏).

[dzdh]

@3dwelcome #156

> 你可以确保自己的服务器万无一失，可客户服务器凭什么去保证不会被挂什么木马？
客户端环境都木马了，你的签名 KEY 还有何安全可谈？

[dzdh]

@chinvo #157

正解

[chinvo]

另外有一些系统不方便进行 mutual tls authentication, 因为 mutual tls authentication 是站级的, 不能对不同路径单独设置. (确实有相关实现可以区分路径设置 mutual tls, 但是这种行为是不标准的, 对不同的 客户端 /服务器 /代理 实现可能有不同表现)

RFC8446 section-4.6.2 定义了类似行为, 但是目前未被任何 HTTP 协议草案包含在内 (甚至被 HTTP/2 草案禁止: RFC8740 section-3).