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

[dzdh]

注意场景：

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

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

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

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

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

[wanguorui123]

@dzdh 其实不考虑特殊情况，携带 Token 或者 Session 加 HTTPS 已经足够安全了

[wy315700]

其实写程序的时候，你永远要考虑对面那端的傻逼行为，要在对方傻逼的时候依然尽可能的保证程序接口可用性。
楼主这么想一想，就知道为啥一些接口会有奇奇怪怪的设计了。


你可能觉得 server to server 加上 标准化的 HTTPS 是一个安全的协议。。

但是如果对面不是 server 呢，直接把接口写到客户端了呢，有见过直接客户端直接连接远程 MySQL 的程序。
再或者是，有人嫌麻烦，HTTPS 关闭了证书验证呢，据了解这么做的不在少数。

[keyfunc]

首先，你不能保证 ssl 隧道肯定安全，密钥泄漏，使用了不安全的密码套件等都会导致 ssl 存在安全漏洞。
签名挑战机制足够简单，越简单的方法越安全。

[newmlp]

tls 只能保证端和端之间是安全的，如果客户端不安全你用 https 没啥用，加个自己的签名可以增加反编译的难度

[crab]

@dzdh 我是说 ssl/tls 防中间人，多个签名防使用者客户。

[wentx]

这个应该是取决于对安全性的要求，像 stripe 这用了 HTTPS + 请求 Sign 的 API 应该就是双重保障，毕竟都是跟钱相关的，如果某个用户的本地被加了一层类似于 Charles 的 HTTPS 代理，那它还可以通过 API 签名来防一手的.

[David1119]

主要不是为了安全，是为了反爬好吗，防止用户把数据都爬走，大部分都是 so 加密算法，增加客户端破解难度

[timedivision]

安全没有绝对的，为了更安全，谁都愿意多加几道锁就好比我把钱放保险柜里，我保险柜不还得放家里吗？难道我把保险柜放外面？

[kejialiu]

@dzdh 一个设计合理的请求签名算法中，所有有含义的请求参数都是被签名的对象，任何参数的修改都会导致签名失效，所以被拦截了也就只能重放那一个特定请求而已。更别说还有时间戳限制有效时间。总体原则就是，如果拦截不可避免，也要把损失降到最小

[borisz]

防抵赖

[kejialiu]

安全从来都是相对的，一般我们是可以认为 https 是可以防中间人的，但这也是有前提的：
- https 服务端的密钥是怎么管理的，都有谁经手了，不小心泄露了呢？
- 浏览器这样的客户端是否可信任呢？里面会不会装了莫名其妙的插件钩子呢？
- 签发 https 证书的 CA 是不是足够可信任呢？

根据你的应用的敏感级别，这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1，意思就是你总是要多做一层防护，让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。

[borisz]

https 只能表示传输的数据时正确的, 但是能保证传输的数据对于系统时无害的,

例如平台内部用户伪造支付请求, 或者内部大量无效请求, 测试需求发送到业务服务器.

[Telegram]

这是概念混淆啊，照你意思是用了 https，用户就不需要账号密码了？

[no1xsyzy]

SSL/TLS 不能确定对方是否对你的证书进行了验证。
双边证书使用相对麻烦。
然后还有遗留问题和习惯问题。

[VHacker1989]

任何客户端做的校验都是多此一举，逆向，动态调试，xposed hook 都能破解和获得密钥，因为客户端完全掌握在用户手里

[Marinaaaa]

给不怀好意的人增加更多破解成本。如

[Marinaaaa]

如果是服务端对服务端，且都是内部系统，内网访问的话，感觉没太必要。如果非内网访问的话可能还是有点风险吧

[hxndg]

只能说明两个现象：
1 很多人对于 TLS 的理解是一知半解的，TLS 本身是非常灵活的，可以根据需求变更 auth/enc/verify 等功能，好多人只知道个 enc 就完了，建议重新研读下 RFC，上面的回复里面有明显的错误。
2 TLS 层安全开发做的不到位，很多的功能原本是明文的，为了一些安全的功能采用了打补丁的方式，而 TLS 加入以后处于兼容性功能或其他方面考虑没能去掉这些补丁。 毕竟国内做业务的和我们这些做基础服务的关注的点不同。

[walpurgis]

@Telegram 因为传输层可以保证安全的话，密码可以直接明文传了，不需要将密码再套一层 HMAC 了

[3dwelcome]

"Pinned Pub Key 还怎么中间人呢？防止客户的什么呢？"

能做到这种验证毕竟是少数，大部分服务器就校验了一下对方 CERT 有效性，因为 CERT 会过期，客户定期会换，你又没办法一直保证服务器存有对方最新的 KEY 和 CERT 来校验。

而且我看所有有钱有关的网络支付，都带签名。

这其实和数据库是不是存用户明文密码是同一个问题：反正用户又看不到服务器上具体有什么，不存 hash，直接存明文是不是一样的？（学一下楼主额外描述：服务器不可能被攻破，因此黑客攻击不在考虑范围内）