拒绝 API 在公网裸奔之实现过程

[jss]

（先忽略 Https ）不想让 API 数据在公网中裸奔于是查了一些方案，比如：jwt des aes rsa 等，最终组合一个理想解决方案：Rsa+Aes; 客户端生成 Aes 密钥 将请求参数进行 Aes 加密,然后，Aes 密钥通过 Rsa 加密一并提交给服务器，服务器通过 Rsa 解密获得 Aes 密钥，进行 Aes 参数解密处理，最后通过解密后的 Aes 密钥加密返回给客户端，实现，公网传输加密。

[alvin666]

这不就是自己实现了 https ？

[chendy]

所以为啥不用 https 呢

[tomczhen]

有种技术叫 HTTP 双向认证，了解一下？

[ayase252]

加上证书验证差不多就是 HTTPS 了啊

[yuikns]

jwt 和此处有什么关系……？

[des]

所以为什么不用 https ？？？

[weizhen199]

https api 除了抗重放以外还差什么吗

[Immortal]

所以为什么不用 https+jwt

[yuikns]

现在还有人分不清 Password 和 Encryption ？

[honeycomb]

@des
@Immortal
这个人自称宁可发明一遍 HTTPS 也不要用 HTTPS

[chinvo]

你这和 HTTPS 有啥区别

[xiangyuecn]

@weizhen199 #7 你的意思 https 包能重放？ https 原生抗重放吧

[masker]

重定义 HTTPS ？

[lhx2008]

有鬼用，没有证书验证是否服务器是服务器发出的公钥，第三人半路拦截就可以发一个他自己的公钥了。完全不可靠。

[lhx2008]

@xiangyuecn https 应该不能抗重放吧，还是可以重发加密包的

[xiangyuecn]

@lhx2008 我觉得除了明文外，重放是最恶劣的底层协议缺陷。如果 https 能重放，那比 http 优越不到哪去，还不如回滚到大家都用 http 的时代，轻快省力，就是裸奔了点。重发≠重放，服务器收到这种包直接丢弃好像。

[yzwduck]

@lhx2008 在正常密钥交换的情况下，HTTPS （ TLS 本身）就抗重放。重发的包不会影响上层应用数据内容，最多服务器认为协议异常而终止连接。
https://security.stackexchange.com/q/20105

[lhx2008]

@xiangyuecn
@yzwduck

谢谢，确实，中间人无法重发 TCP 包来做重放攻击，但是业务上还是得做随机数来防止在客户端上的重发。还有一种比较高成本的第三人攻击是可以通过中断 TCP 回程，迫使客户端重发。

[dawniii]

@lhx2008 感觉您说的不是重放，而是业务上的幂等。

[jimrok]

@lhx2008 https 无法重放，https 的握手建立过程中，server 决定每次的交换密钥，所以，无法回放加密的包来建立握手。另外 https 还有前向安全性，及时偷走了服务器上的主密钥，你也破解不了历史的加密包。