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

[dzdh]

注意场景：

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

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

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

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

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

[sekfung]

SSL Pinning 安全性问题，见#88 楼
我赞同#100 楼说的，就是不同层次的做法。

逆向与反逆向就是道高一尺，魔高一丈，安全领域没有绝对性的安全，只有提高破解的成本。

[3dwelcome]

@dzdh "所以是，仅仅 HTTPS 已经足够安全，所谓签名只是锦上添花？"

光"锦上添花"就很重要，支付 API 设计能强过竞争对手，才能抢到足够的市场份额。

你开发一个 HTTPS 网站，去做网站安全评级，每一个服务器设置的细节，都是打分点。
你开启一个云服务器站点，服务器平均无故障就是一大卖点，数 99.99 小数点之后有几个 9，就能比同行抢到更多的用户。

支付签名设计也是一样，能给 API 安全打分后面加个 9，何乐而不为。

[dzdh]

@catchexception 100

对的。『签名机制』的目的是为了防止在『传输时』被篡改（被截获倒不可怕）。

且我认为就只有这一项作用了，而 HTTPS 的存在就足以保障『无限接近 100%』的传输安全，因此有此一问，为何当下大厂在『有 HTTPS 的前提下还要有签名机制辅助』

[akira]

@LeeReamond 这是反话呢。。

[dzdh]

@sekfung 101

对于#88 楼的回复见 #96 楼

SSLPinning 被攻破，仅仅是单个客户端的安全（而且绝大多数情况下是自己搞得）。
而『签名』的密钥通过 HOOK 方法一样也能轻松拿到，而且拿到签名密钥是不是意味着所有的客户端都不安全？

[dzdh]

@3dwelcome 102

所以，『纯技术』上，在有 HTTPS 保护的前提下，签名没有『必要性』

[3dwelcome]

@dzdh "所以，『纯技术』上，在有 HTTPS 保护的前提下，签名没有『必要性』"

那是自然，只要 PC 机器能 [物理隔绝] ，使用时只有机主一个人能进入密室访问电脑，那 windows 登录密码也没有存在的 [必要性] 。

[dzdh]

@3dwelcome 107

如果一个密码公开发放，那的确没有必要性。

[3dwelcome]

@dzdh "如果一个密码公开发放，那的确没有必要性。"

密码怎么可能公开？举个例子，微信支付的 url 签名 hash 算法是 HMAC, 也就是需要 key 才能使用的 HASH 算法。这个 key 是严格保密的，外人肯定不会随便知道。

[hxndg]

@catchexception
@ashuai

你俩的对话可以完美对接，

实际上我看到 ashuai 的回复的时候也是想的这个，不过后来想想算了，国内的很多程序员就是喜欢层与层之间要通信，而不是只提供依赖。
我这几年写 TLS 自动机的最大感受就是国内很多程序员就是不分层，一部分问题确实不分层比方说四层的零信任，但是很多业务层的事情非得扔给 TLS 做导致极其不灵活。

@dzdh
为什么要和一群根本不知道 TLS 做了什么的人讨论具体细节呢？一个合格的程序员（架构）必然会拆分不同的层做不同的工作，你自己都明明知道咋回事何必争论呢？

[dzdh]

@3dwelcome

同样的『客户端证书』也是严格保密的，外人肯定不会知道

[dzdh]

@hxndg

因为最近的业务设计思来想去决定仿照 Stripe 的接口风格，想集思广益证明『单纯的 https 』不安全。

[dzdh]

@hxndg 然而发现自己都说服不了自己，反而越来越认为这样是『对的』，签名模式并没有存在的必要。

[dzdh]

@dzdh #111

抛弃『客户端证书』，`curl -u $ukey ..` 的 $ukey 也是『严格保密』的

[3dwelcome]

@dzdh

"同样的『客户端证书』也是严格保密的，外人肯定不会知道"
不不，客户端证书和微信商户 KEY 安全性没法相提并论。

客户端证书获取流程是写进 SSL 规范里的东西，你比如访问 api.mch.weixin.qq.com 之类的网站，只要服务器发一个 CERTIFICATE_REQUEST 请求，客户端就会乖乖主动发证书发给对方，也不知道对方是真是假。

但是微信商户 KEY 不一样啊，默认就是私密存放，不发给别人的。除了去登录微信的开发账号查看，没别的办法获取到了。

[dzdh]

@3dwelcome #115

1. 抛弃『客户端证书』，`curl -u $ukey ..` 的 $ukey 也是『严格保密』的
2. SSLPinning
3. SSLPinning 被攻破代表着已经控制了物理设备，控制了物理设备可以直接读取所谓的『 KEY 』

[dzdh]

@3dwelcome #115

另外补充一下，发送的是用于加密认证的的客户端证书公钥，不是私钥。

[3dwelcome]

@dzdh “2. SSLPinning”
你这就是先有鸡还是先有蛋的问题，SSL Pinning 的前提，就是双方验证对方的证书。然而你证书不发送出去，又何来验证一说？但是你一旦发送，你的客户端证书就有可能被泄露。

学一下微信 KEY 多好，只签名不发送，稳妥多了。

[dzdh]

@3dwelcome 118

客户端证书我可以直接挂出来公开都行，没有私钥你拿到公钥没有任何意义。

比如我微信支付商户的证书公钥你要吗？我发给你。

[swulling]

最早是用在 http 情况下防止重放攻击的。

后来换 https 后设计就没用了，但是要么同时提供 http https，要么就是保持历史代码兼容，所以也就不改了。