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

[dzdh]

注意场景：

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

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

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

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

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

[screen]

大多数攻击来自客户端的截取、伪造而非信息传递中

[xmumiffy]

是没必要

[dzdh]

@screen 如果 SSLPinning 无效的话，那客户端用『签名』也一样能截取啊

[dzdh]

@xmumiffy 国内大厂是出于什么样的考量呢？

[iyaozhen]

签名我记得是两边约定一个 token，把参数和 token 签一下，更安全

一般用在开放接口上吧，就是接口参数大家都知道，你别的地方不小心泄露参数了，就有风险

[xmumiffy]

@dzdh 十年前 http 年代我们是这么做的 现在也没必要改

[des]

我猜测可能是这几个原因
一是方便用 http，http 也方便调试
二是即使是服务端对服务端，走的是统一的网关，不想再搞一个域名
三是不少人对 https 认识不那么够，不会搞证书认证，毕竟资料也少，相对于签名

[dzdh]

@des

1 理解
2 网关统一 HTTPS 不是更简单了么都不用再配置啥
3 emmmm 理解

[momocraft]

签名虽然现在看觉得傻 十年前不失为一个 http 下能加密+防重放攻击的方案

另外市场地位不一样 要是 stripe 敢像企鹅这样一个 QR 码写出不到十种 API 可能活不到上市

[akira]

你要这么说的话，服务端对服务端 http 就够了，ssl 都不需要上

[ihipop]

现在很多方案是前端 HTTPS 网关后面业务系统是 HTTP，如果做使用客户端做 SSL 认证，整个系统都需要要改造，不可能业务系统身份认证全做网关上吧？ SSL 只 pin 服务端的证书没法验证客户身份，签名不仅仅可以防篡改，还能客户做身份认证

[dzdh]

@ihipop 还好吧，客户端证书在网关直接验证好的，到后面的 HTTP 业务的时候直接带着 https_s|c_xx 的 header 头的哇而且还伪造不了

[dzdh]

@ihipop 不是老系统改造，是新系统

[wooyuntest]

加大直接构造数据向接口发请求的难度（还得逆向 app 拿到签名算法）

[dzdh]

@wooyuntest 找密钥吧。这是客户端场景了，即便如此，仅使用 HTTPS 直接传递 ukey 的话也得逆向啊。
HOOK 方案的话无论任何方案都没辙吧。

[kejialiu]

签名是一次性的，只针对这个请求，就算被截获了也伤害不大。密钥不管什么原因被泄露了，后续所有请求都可以伪造，所以能不暴露就不暴露，哪怕是加密通道

[dzdh]

@kejialiu

一次性的根本原因是因为有 nonce 。以此为目的达到防 Replay Attack 。

但是究其根本，HTTPS 本身被抓到已有也是个无法篡改的普通 TCP 数据包。重放攻击也只能将这个数据包无数次发送给对方服务器。也就是说，只要在普通的请求参数中加入任意一个具备 nonce 特性的参数如 timestamp，那这个数据包依然可以被直接拦截。

同时，如果说 HTTPS 不用构造直接可以无限次任意请求的话，签名模式难道就不是吗?

[dzdh]

@kejialiu

即便没有 nonce 。如 http://domain/path?order_id=x&sign=n 。是的没错，这个请求无法被篡改，但是我依然可以肆无忌惮的发起查询啊。

而且肯定是要有一个『某 ID 』的参数吧？如商户 ID 、用户 ID 等标记唯一应用的参数吧。那也就是说，只是某一个『用户』或『应用』能构造针对特性对象『 order_id=x 』的请求。

那相应的，HTTPS 的话直接作为 Authentication Header 参数放进来一样的哇。

[Vegetable]

这个有历史的惯性原因吧，大家都有签名，我这没签名显得不安全。

另一个可能是，对于在网络请求中传递密钥的恐惧？我这两天正在设计一个 s2s 接口，也非常纠结到底要不要做签名

[ch2]

过滤掉不会签名的傻子，仅此而已