@BinaryLeeward #130

SSLPinning

@3dwelcome #132

不是那个问题。

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

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

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

@kejialiu #128


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

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

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

:doge: 进不去就对了

@3dwelcome #125

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

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

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

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

@jim9606 #123

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

@jim9606 #123

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

@3dwelcome 118

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

@swulling #120

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

@3dwelcome 118

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

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

@3dwelcome #115

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

@3dwelcome #115

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

@dzdh #111

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

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

@hxndg

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

@3dwelcome

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

@3dwelcome 107

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

nginx proxy_protocol