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

[dzdh]

注意场景：

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

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

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

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

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

[dzdh]

@swulling #120

补充应该还有个『鉴权和身份验证』的功能如『?uid=X&order_id=N&sign=Y 』要验证 uid 是不是 uid

[dzdh]

@3dwelcome 118

补充，SSLPinning 的前提，只需要知道对方服务器的证书公钥即可。不需要『双端验证』

[jim9606]

API 接口搞一套自订签名的目的是适应不能使用 TLS 双向认证的情况，例如：
1. client 环境存在强制部署的 MITM 代理
2. CDN/API 网关服务 /高防服务不支持客户端 TLS 认证透传，或者位于网关后的 API 应用服务器不能获得充足的客户端身份信息，例如网关做了统一 TLS 解密
3. 任一端无法保证系统时间准确
4. API 服务器所使用的网络框架难以适应 TLS 客户端认证的需要，例如异步 request handler 没有方法获取来源的 TLS 连接状态，或者需要重复解析客户端证书信息导致性能瓶颈
5.客户端采用精简的 TLS 实现，不支持双向认证

第二点在很多企业中是个麻烦事，如果你确定这套 API 只用于支持端对端的 TLS 双向认证的环境，而且有能力维护签发 /吊销客户端证书的附属系统，那确实可以只依赖 TLS 双向认证。

如果希望服务器认证也完全在自身掌控之中，服务器也可以使用私有 CA 签发的证书，客户端配置只信任私有 CA 即可。
PKP 是用来防止第三方 CA 滥发证书的，且有很多实践上的问题，已经被弃用。

[dzdh]

@jim9606 #123

1. 强制出网 HTTPS 请求走代理？什么场景？需要做审计么？
2. Stripe 和 Paypal 的全球 CDN 的解决方案是什么？高防服务可以数据包转发。抛弃『客户端证书不谈』，就单纯的仅『 HTTPS 』形式如标题的『 curl -u $ukey https://....』貌似并不存在这问题？全链路保证 https （ cdn https 回源）
3. 签名需要的 TIMESTAMP 参数也无法保证
4. 性能问题？
5. 服务端强制要求的密码套件设置呢？

[3dwelcome]

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

微信没有公钥，在 url 签名算法里，只有商户平台设置的密钥 key，这个绝对不能发给别人，绝对不能在网络上流传，必须严格保密。

公钥和商户 KEY 的区别，就好比一台联网的 PC 和一台物理断网的 PC 差别，你说哪一个更安全？

[dzdh]

@jim9606 #123

补充。PKP 是浏览器应用废弃，在 Server 到 Server 场景中依然可用。浏览器端的安全由浏览器自己实现。

[dzdh]

@3dwelcome #125

curl -u $ukey https://...

$ukey 只有商户平台设置的$ukey，这个绝对不能发给别人。

> "这个绝对不能发给别人，绝对不能在网络上流传，必须严格保密。"

你的意思是破解了 HTTPS ？？？？？？破解了 ECC ？？从而拿到了我的数据包？

[kejialiu]

@dzdh - https 服务端的密钥是怎么管理的，都有谁经手了，不小心泄露了呢？
回：签名模式的密钥怎么管理的？都谁经手了，不小心泄露了呢？

不是这个意思。我作为参与通信的其中一方，无法保证对方的安全管理足够好，我最多只能控制自己这一边。对于使用了 https+签名的情况，从服务端的角度看，某个客户的签名密钥泄露只会影响这个特定的客户；从客户端的角度看，服务端的 https 密钥泄露等同于通信变明文，但别人还是伪造不了我的签名。两种情况都比最好情况好很多。

- 签发 https 证书的 CA 是不是足够可信任呢？
回：本地指定 CA 文件验证

这个指的是 CA 本身被攻击，导致客户密钥泄露，甚至主动参与犯罪 /配合有关部门。当然这种可能性很小，但小不等于没有。

以上讨论的出发点都是 “https 防中间人是有条件的”，与题主的问题没有直接关系。

再多嘴一句，其实 https 网站很多很多时候都不是全链路加密，tls termination 发生在负载均衡，甚至更前面的某个第三方(比如 CDN 或云厂商)的反向代理或者所谓应用防火墙上上，后面都是明文，就算是在内网，走明文也是非常不安全的。

[nikan999]

猜测可能是为了保证端到端的数据不会发生错误。保证应用层的数据完整性。

[BinaryLeeward]

个人觉得纯粹的服务端对服务端的场景有了 https 和密钥就够了，再加签名机制是没啥用，但是作为服务提供方是无法强制调用方一定得在服务器调用，如果调用方直接在客户端调用了接口，如果不用签名的机制那随便抓个包就拿到密钥了跟裸奔差不多，用了签名机制至少加了一层安全性必须破解客户端才能拿到密钥。

[dzdh]

@kejialiu #128


1+2. Server 端到 Server 端可以自签名证书。

泄露就也就是指的服务器攻击或者或主动或被动的泄露。
- 被攻击泄露，如果服务器被攻击且能读取到 ssl 证书的文件内容本体，我认为数据库也已经不安全了，所有商户的签名 key 也都不安全。
- 或主动或被动的泄露证书私钥，攻击成本他需要控制全国骨干网管理节点或攻破我 DNS 系统，最次也要控制某单个客户的服务器（ server 端）或某单个用户的家庭网络，受影响的也仍然只是某单个用户吧？

链路问题可以设置成全链路 tls 吧？如 cloudflare ？阿里云、腾讯云等众多 CDN 厂商的 cdn 也是支持 https 回源的

[3dwelcome]

@dzdh “curl -u $ukey”

商户 key 不是这样用的，商户 key 是 hmac 算法的关键。SSL 里同样也有 hmac 算法，key 叫 master key，如果你有幸拿到了，那恭喜你，就真正意义上攻破了 HTTPS，喜大普奔。

[kejialiu]

@dzdh 看了一下你的其它回复，在＊有客户端证书＊的情况下确实没必要对请求额外签名，这两个原理上是等效的，或者说签名只是客户端证书的屌丝版。

[dzdh]

@3dwelcome #132

不是那个问题。

而是，我设计的就是这样的，$ukey 就是我的商户 key 。

和你所谓的微信商户 key 同等权限（在应用设计上），微信商户 key 用来计算生成 hash 或 hmac，不参与网络传输，ok，没问题。

我的$ukey 在公网传输，但是有 https 保证不被泄露啊？有什么问题吗？

[dzdh]

@BinaryLeeward #130

SSLPinning

[kejialiu]

@dzdh 链路问题可以设置成全链路 tls 吧？如 cloudflare ？阿里云、腾讯云等众多 CDN 厂商的 cdn 也是支持 https 回源的

其实这里还有一个问题是你要把 https 私钥分享给 CDN 厂商，这些大厂就这么可信吗？反正我胆子很小。。

[dzdh]

@kejialiu #136

对的，也就是纯『技术上』说，『仅仅 HTTPS 不使用签名』其实并无问题？

[kejialiu]

@dzdh 纯『技术上』说，『仅仅 HTTPS 不使用签名』其实并无问题？

这样的说法有一定误导性，当今 https 最广泛的应用场景都是不使用客户端证书的，还是需要强调一下

[BinaryLeeward]

@dzdh 你说的没错 SSLPinning 某种程度上是可以防抓包，但是我想表达的场景是，调用方可能并不会按常规的方式来操作，假如我是服务提供方，我根本没法强制客户按照我的想法设计 app， 假如客户就是直接在 app 端不做任何安全措施就调用了接口，那对于服务提供方来说接口的安全性肯定是差了很多，这种情况下，加个签名机制简单又有效。

[dzdh]

@BinaryLeeward #139

同理，假设客户直接在 app 端不做任何反编译防护措施，直接把密钥明文贴在配置文件中，签名机制就没有一丝一毫的作用？