@xiangyuecn 您前面说的客户端被种恶意根证书，黑客有这个权限的话，在客户端那边黑客该有的不该有的权限基本也都有了。。。

后面说的 xss 和 csrf 本来就不是 tls 负责的，这算是业务上面的漏洞。tls 只是保证数据在传输过程中的安全，应该是满足 up 的需求。

@xiangyuecn 是指不校验证书的情况吗？不校验证书为什么用 tls 呢。。。

@a7a2 想了想得分两种情况来看，服务端调用还是客户端调用。
如果是在服务端调用 api，这个 md5 里有一个保密的 secret，篡改的难度还是挺大的。如果是客户端调用的话，就会比较不堪一击了。

@a7a2 如果被这么高权限机构的针对，那么自己写的类似 md5 签名方法，感觉也是不堪一击啊。。。

@dawniii 非常感谢大家的回复，受益匪浅。上面很多说的重放，原来是指的业务上的重放。

@seeker 发的这篇文章挺好的，解释了为什么 tls 不会被中间人重放。

http://blog.valverde.me/2015/12/07/bad-life-advice/

TLS 通过为每个连接导出一组新密钥并为每个记录分配唯一的序列号来保证加密流是不可重放的。
这可以防止攻击者复制这些记录并在另一个连接上重放这些记录，因为加密密钥不匹配。
在同一连接上重放它们也不起作用，因为序列号不匹配，并且记录将被拒​​绝。

但是中间人可以破坏连接，有的客户端会实现自动重试一次，这样来达到客户端自己重放的效果。

一般类似支付的接口，应该都是有业务状态来保持幂等的，发生重复支付的几率应该很低。

@honeycomb 您说的客户端抽风等原因，导致重复发帖的问题。貌似用到 nonce timestamp 来做请求的验证就行。并不需要再加一个 md5 校验，因为 tls 已经保证了请求的完整，感觉 md5 这部分事情做的重复了。

暂时的结论是 https 已经满足大部分场景，保证了请求的完整、不被篡改、加密。
md5(secret+参数+时间戳)这种方式，有两个作用。第一个是防止业务上的重放（如果只是防止业务重放是没必要 md5 的），第二个是增加恶意调用接口的门槛。

@zjp @FanWall 多谢两位的回答。有点疑惑的是，你们说的重放是指中间监听密文重放吗？我记得 ssl 的密文是有序号的，不知道能不能防止这种重放。可能我理解的有偏差。

给他看看这个 http://tinyclouds.org/jsconf2018.pdf

doge

@gouchaoer 如果你在 fpm 里面查询 mysql 的话就阻塞了，流量一大就会死得很惨。。。🤣

风格和宁浩网挺像的 ninghao.net

https://i.loli.net/2018/01/04/5a4e3e65e5a87.jpg

上面都在说什么 哈哈

拉低中奖率！