注意场景：
综合以上三点。为什么在 Https 的保护下，还要额外做签名验证？
主要疑问，如 stripe 的退款接口
curl https://api.stripe.com/v1/refunds -u "$密钥:" -d charge=$charge_id 就可以发起一笔订单的退款或者扣款。按照某些论述的话，没有签名的 Stripe 岂不是非常危险？
一般用在开放接口上吧，就是接口参数大家都知道，你别的地方不小心泄露参数了，就有风险
1 理解
2 网关统一 HTTPS 不是更简单了么都不用再配置啥
3 emmmm 理解
另外市场地位不一样 要是 stripe 敢像企鹅这样一个 QR 码写出不到十种 API 可能活不到上市
一次性的根本原因是因为有 nonce 。以此为目的达到防 Replay Attack 。
但是究其根本，HTTPS 本身被抓到已有也是个无法篡改的普通 TCP 数据包。重放攻击也只能将这个数据包无数次发送给对方服务器。也就是说，只要在普通的请求参数中加入任意一个具备 nonce 特性的参数如 timestamp，那这个数据包依然可以被直接拦截。
同时，如果说 HTTPS 不用构造直接可以无限次任意请求的话，签名模式难道就不是吗?
即便没有 nonce 。如 http://domain/path?order_id=x&sign=n 。是的没错，这个请求无法被篡改，但是我依然可以肆无忌惮的发起查询啊。
而且肯定是要有一个『某 ID 』的参数吧？如商户 ID 、用户 ID 等标记唯一应用的参数吧。那也就是说，只是某一个『用户』或『应用』能构造针对特性对象『 order_id=x 』的请求。
那相应的，HTTPS 的话直接作为 Authentication Header 参数放进来一样的哇。
另一个可能是，对于在网络请求中传递密钥的恐惧？我这两天正在设计一个 s2s 接口，也非常纠结到底要不要做签名
参见 18 。
如 http://domain/path?order_id=x&sign=n 。是的没错，这个请求无法被篡改。
我可以直接不停的直接请求，这就是重放攻击对吧？那就单单是『签名』是怎么防止重放攻击的呢？难道不是 API 的露酒设计来检测 order_id 的请求次数么？或者 sign 的请求次数么？无论是否是签名都需要做这一步啊？
我一直怀疑我的键盘坏了 …
上不是很多人都说了吗？
ssl 防御的是中间人攻击
而签名是防御：非授权客户的额外请求
不是一个场景
但是针对某一个资源的操作如 x_id=N，只要我接口保持幂等，无所谓重放不重放吧？对实际业务 0 损失啊？即便有签名，也只是根据 timestamp 和当前服务器时间的差值决定是否拒绝请求，但是请求依然进来了啊。
这个『授权』是怎么定义呢？签名怎么体现『授权』呢？客户端证书是否也能实现呢？
key 是 被调用方 分配 /颁发给 调用方，或调用方主动在被调用方处登记注册的。如帐号密码
> 注意场景是 Server To Server
1. API 的接口设计的逻辑是否可以要求下单的时候带上一个发起方的 ID 呢？这个 ID 不就是个 nonce 么？根据这个 ID 也可以防止某个内部服务重复下单啊（注意场景是 Server 端到 Server 端，如 stripe 、paypal 、支付宝、微信的预下单接口）
2. 是否可以直接生成一个加密 token 在 token 里直接绑定 ip 、时间戳，然后这个 token 一次有效呢？只能由 openssl 解密（是的，没有仅仅只依靠 HTTPS ）
我指的签名仅仅指的是：按照规则排序然后拼字符串使用 shaX/mdX 的形式
你可能觉得 server to server 加上 标准化的 HTTPS 是一个安全的协议。。
但是如果对面不是 server 呢，直接把接口写到客户端了呢，有见过直接客户端直接连接远程 MySQL 的程序。
再或者是，有人嫌麻烦，HTTPS 关闭了证书验证呢，据了解这么做的不在少数。
根据你的应用的敏感级别，这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1，意思就是你总是要多做一层防护，让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。
例如平台内部用户伪造支付请求, 或者内部大量无效请求, 测试需求发送到业务服务器.
能做到这种验证毕竟是少数，大部分服务器就校验了一下对方 CERT 有效性，因为 CERT 会过期，客户定期会换，你又没办法一直保证服务器存有对方最新的 KEY 和 CERT 来校验。
而且我看所有有钱有关的网络支付，都带签名。
这其实和数据库是不是存用户明文密码是同一个问题：反正用户又看不到服务器上具体有什么，不存 hash，直接存明文是不是一样的？（学一下主额外描述：服务器不可能被攻破，因此黑客攻击不在考虑范围内）
@no1xsyzy 你的证书是谁的证书？ TLS server 端还是 client 端？
@Telegram 用户名和密码是保护什么？签名是保护什么？
@borisz 所以签名能保证数据对系统无害？
你说的废除，只是 chrome 浏览器里定下的规范。主这里没有浏览器的参与。
1 首先公钥钉扎，或者说公钥固定（ whatever ）不单纯针对浏览器，任何涉及到 TLS 的都会做，我们实现了钉扎，但是国内没人用，最后没进正式 build，代码被废除了。国内没有一个运营商采用这东西，几大银行更是提都不提。
2 chrome 废除了这个确实，这点我确实说错了。
对的，只是 Chrome 废除而已，无论是 Server 端还是 Client 端，只要你验证，依然是可以进行服务端身份鉴别的啊
密钥泄露和签名所用的密钥泄露是同等效的，那同样也不能证明『签名机制』的安全。该理由不成立
同理可证明，如果客户端不安全（如『签名模式』的密钥摆在明面上），那『签名机制』远没有『 HTTPS 』安全。该理由不成立。
Charles 是依靠『中间人』来进行抓包的。
其次，如果真的使用 Charles，那是不是就意味着其已经控制了『物理机』？在控制『物理机』的前提下还有什么安全方案是可以保证『全安』的吗？ 并不能证明 HTTPS 环境下，签名模式的『必要性』
接口设计要求 CleintID，爬虫场景完全可以屏蔽 ClientID 。
其次，标题是 Server 端到 Server 端。即便是用户不小心暴露 API，依然可以屏蔽 ClientID，中断爬虫行为。该理由不成立。
请阐明就目前技术手段方案中，HTTPS 前提下，签名模式的『必要性』
比如？
比如下单场景，可以要求调用方生成唯一『请求号』，在接口设计逻辑上可以进行规避。
有没有什么场景是『无法』进行规避的？
HTTPS 防止中间人有 SSLPinning 的方案，足矣无限接近 100%的保障安全（请提出反对意见）
– https 服务端的密钥是怎么管理的，都有谁经手了，不小心泄露了呢？
回：签名模式的密钥怎么管理的？都谁经手了，不小心泄露了呢？
– 浏览器这样的客户端是否可信任呢？里面会不会装了莫名其妙的插件钩子呢？
回：Server 端到 Server 端，签名模式就能规避『莫名其妙』的钩子是吗？
– 签发 https 证书的 CA 是不是足够可信任呢？
回：本地指定 CA 文件验证
根据你的应用的敏感级别，这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1，意思就是你总是要多做一层防护，让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。
回：所以是 HTTPS 足矣保证安全，仅仅只是为了多加一层兜底手段，对吗？
所以 paypal 和 stripe 两个平台是极度危险的是吗？
– SSL/TLS 不能确定对方是否对你的证书进行了验证。
回： ？？？
– 双边证书使用相对麻烦。
回：签名排序参数使用密钥拼接参数字符串不麻烦吗？
– 然后还有遗留问题和习惯问题。
回：如？
所以安全就不用做了呗？无论你做任何安全都可以被逆向、动态调试？
同理，如果客户端环境安全无法保证的前提下，怎么保证『签名模式』是安全的呢？
在思考这一点之前，先思考如何保证『签名模式』下对方一定也是 Server 端。
我的接口是为了 Server 端调用而设计，客户错误使用暴露出去，屏蔽 ClientID （调用凭证）即可
例如我给服务器发 123456，因为网络抖动，结果服务器有可能只收到 1234
有以上可能吗？如果有，这就是签名的意义
不过如果依赖于 HTTPS （这里需要注意证书），这两都可以不要。我觉得可能现在还这么做的大厂，惯性更多一点吧，毕竟代码已经写好了，可以跑了，改设计，没必要。
你用国外网站举例没意义，国外信用卡支付没密码是安全的，放国内基本不可能。
同理国外电子支付没有签名是安全的，国内设计的 API 没签名？想都别想，和钱有关的，必须加码，管他有没有用。
这和软件加壳一个道理，你不知道破解者的能力和权限（说不定就是你隔壁同事），越套一层防范，单纯从理论上来说，就能阻断一部分破解者的尝试，也就变相代表着越安全。
就安全系数来说，有签名的 API 和没签名的 API PK 一下，有签名的得分高。光刷公司的 KPI，也必须加。
为了支付系统上出 BUG 可以甩锅，小码农根本赔不起。“看，API 设计够好了，还有签名！”
“有以上可能吗？如果有，这就是签名的意义”
没可能
> Server 端到 Server 端。
同理，HOOK 也可以轻松拿到用于『签名模式』的签名密钥，so easy~
> 管他有没有用
所以并不是出于安全考虑，就是为了『加』而『加』？
> 你用国外网站举例没意义，国外信用卡支付没密码是安全的，放国内基本不可能
公共网络的、任何人都可以进行调用的、处于公网环境的 HTTPS 接口，甚至有详细的文档。为什么他就『安全』呢？支付宝接口如果不用『签名』设计就『不安全』了？比如如果支付宝现在开始不用签名了，会导致什么问题呢？包括但不限于下单、退款、关闭订单、转账等接口，就直接像 stripe 一样 `curl -u $key https://api.alipay.com/api/transfer?to=xxx&amount=1000` 。
如果有签名的时候被黑了呢，接口 bug 了呢 这不是一样吗
所以是，仅仅 HTTPS 已经足够安全，所谓签名只是锦上添花？