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

[dzdh]

注意场景：

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

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

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

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

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

[hxndg]

@Marinaaaa 内网访问没有必要这个目前已经被认为是错误的了。

@no1xsyzy 你的证书是谁的证书？ TLS server 端还是 client 端？

@Telegram 用户名和密码是保护什么？签名是保护什么？
@borisz 所以签名能保证数据对系统无害？

[hxndg]

@3dwelcome
那东西叫做公钥钉扎，防备中间人，已经废除了。
此外
签名和数据库存储明文密码根本不是一个概念，每个步骤都是有其基本目的的，签名是用来防抵赖，抗修改+重放的
数据库不能存储明文用 hash 是对抗内部攻击，泄漏的

[3dwelcome]

@hxndg
"那东西叫做公钥钉扎，防备中间人，已经废除了。"
不不，楼主说的是 Server to Server 上的 PubKey 验证，就是直接在 TLS 握手阶段，读取证书里的 pubkey，看是不是和数据库里的一致，服务器要额外写一些入侵式代码。

你说的废除，只是 chrome 浏览器里定下的规范。楼主这里没有浏览器的参与。

[xuanbg]

SSL 是可以保证数据传输的安全，但也仅仅是保证数据传输过程安全而已。数据在传输前是不是伪造的？这个 SSL 可没法保证。

[hxndg]

@3dwelcome

1 首先公钥钉扎，或者说公钥固定（ whatever ）不单纯针对浏览器，任何涉及到 TLS 的都会做，我们实现了钉扎，但是国内没人用，最后没进正式 build，代码被废除了。国内没有一个运营商采用这东西，几大银行更是提都不提。
2 chrome 废除了这个确实，这点我确实说错了。

[AlisaDestiny]

其实这就像登录密码和支付密码，登录密码只能确定付款方身份是你，但这并不代表这次的支付请求是由你本人发起（比如你室友趁你睡觉的时候拿你手机给自己转账），所以需要你输入支付密码确认。

[dzdh]

@newmlp 如果客户端不安全『签名机制』也没啥用，这个理由不成立

[dzdh]

@AlisaDestiny 这个场景『签名机制』也没用，因为如果『支付密码』你泄露了呢？安全上两个方案一样的，甚至不如 HTTPS

[dzdh]

@xuanbg HTTPS 能够保证传输安全已经足够了，真正的 API 请求安全（身份鉴别）不是依靠其传递的参数实现的吗？直接 HTTPS+HTTP Authenctication 一样的啊？

[dzdh]

@3dwelcome 63

对的，只是 Chrome 废除而已，无论是 Server 端还是 Client 端，只要你验证，依然是可以进行服务端身份鉴别的啊

[dzdh]

@Telegram
几楼或者哪句话有『不需要账号密码』的意思，请指出。

[dzdh]

@keyfunc 43

密钥泄露和签名所用的密钥泄露是同等效的，那同样也不能证明『签名机制』的安全。该理由不成立

[dzdh]

@newmlp 44

同理可证明，如果客户端不安全（如『签名模式』的密钥摆在明面上），那『签名机制』远没有『 HTTPS 』安全。该理由不成立。

[dzdh]

@wentx 46

Charles 是依靠『中间人』来进行抓包的。

其次，如果真的使用 Charles，那是不是就意味着其已经控制了『物理机』？在控制『物理机』的前提下还有什么安全方案是可以保证『全安』的吗？ 并不能证明 HTTPS 环境下，签名模式的『必要性』

[dzdh]

@David1119 47

接口设计要求 CleintID，爬虫场景完全可以屏蔽 ClientID 。

其次，标题是 Server 端到 Server 端。即便是用户不小心暴露 API，依然可以屏蔽 ClientID，中断爬虫行为。该理由不成立。

[dzdh]

@timedivision 48

请阐明就目前技术手段方案中，HTTPS 前提下，签名模式的『必要性』

[dzdh]

@kejialiu 49

比如？

比如下单场景，可以要求调用方生成唯一『请求号』，在接口设计逻辑上可以进行规避。

有没有什么场景是『无法』进行规避的？

[dzdh]

@kejialiu 51

HTTPS 防止中间人有 SSLPinning 的方案，足矣无限接近 100%的保障安全（请提出反对意见）

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

- 浏览器这样的客户端是否可信任呢？里面会不会装了莫名其妙的插件钩子呢？
回：Server 端到 Server 端，签名模式就能规避『莫名其妙』的钩子是吗？

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


根据你的应用的敏感级别，这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1，意思就是你总是要多做一层防护，让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。
回：所以是 HTTPS 足矣保证安全，仅仅只是为了多加一层兜底手段，对吗？

[dzdh]

@borisz 52

所以 paypal 和 stripe 两个平台是极度危险的是吗？

[dzdh]

@no1xsyzy 54

- SSL/TLS 不能确定对方是否对你的证书进行了验证。
回： ？？？

- 双边证书使用相对麻烦。
回：签名排序参数使用密钥拼接参数字符串不麻烦吗？

- 然后还有遗留问题和习惯问题。
回：如？