（先忽略 Https ）不想让 API 数据在公网中裸奔于是查了一些方案，比如：jwt des aes rsa 等，最终组合一个理想解决方案：Rsa+Aes; 客户端生成 Aes 密钥 将请求参数进行 Aes 加密,然后，Aes 密钥通过 Rsa 加密一并提交给服务器，服务器通过 Rsa 解密获得 Aes 密钥，进行 Aes 参数解密处理，最后通过解密后的 Aes 密钥加密返回给客户端，实现，公网传输加密。
This topic created in 2857 days ago, the information mentioned may be changed or developed.
 |
alvin666Jan 13, 2019 via Android
1
这不就是自己实现了 https ？
|
 |
2
所以为啥不用 https 呢
|
2 |
tomczhenJan 13, 2019
3
有种技术叫 HTTP 双向认证，了解一下？
|
 |
ayase252Jan 13, 2019 via iPhone
4
加上证书验证差不多就是 HTTPS 了啊
|
 |
yuiknsJan 13, 2019 via iPad
5
jwt 和此处有什么关系……？
|
 |
desJan 13, 2019 via Android
6
所以为什么不用 https ？？？
|
 |
weizhen199Jan 13, 2019
7
https api 除了抗重放以外还差什么吗
|
 |
ImmortalJan 13, 2019
8
所以为什么不用 https+jwt
|
|
yuiknsJan 13, 2019 via iPad
9
现在还有人分不清 Password 和 Encryption ？
|
 |
chinvoJan 13, 2019 via iPhone
11
你这和 HTTPS 有啥区别
|
 |
xiangyuecnJan 13, 2019
12
@weizhen199 #7 你的意思 https 包能重放？ https 原生抗重放吧
|
 |
maskerJan 13, 2019
13
重定义 HTTPS ？
|
 |
lhx2008Jan 13, 2019 via Android
14
有鬼用，没有证书验证是否服务器是服务器发出的公钥，第三人半路拦截就可以发一个他自己的公钥了。完全不可靠。
|
|
lhx2008Jan 13, 2019 via Android
15
@xiangyuecn https 应该不能抗重放吧，还是可以重发加密包的
|
|
16
@lhx2008 我觉得除了明文外，重放是最恶劣的底层协议缺陷。如果 https 能重放，那比 http 优越不到哪去，还不如回滚到大家都用 http 的时代，轻快省力，就是裸奔了点。重发≠重放，服务器收到这种包直接丢弃好像。
|
 |
17
@lhx2008 在正常密钥交换的情况下，HTTPS （ TLS 本身）就抗重放。重发的包不会影响上层应用数据内容，最多服务器认为协议异常而终止连接。
https://security.stackexchange.com/q/20105 |
|
lhx2008Jan 13, 2019 via Android
18
@xiangyuecn
@yzwduck 谢谢，确实，中间人无法重发 TCP 包来做重放攻击，但是业务上还是得做随机数来防止在客户端上的重发。还有一种比较高成本的第三人攻击是可以通过中断 TCP 回程，迫使客户端重发。 |
 |
20
@lhx2008 https 无法重放，https 的握手建立过程中，server 决定每次的交换密钥，所以，无法回放加密的包来建立握手。另外 https 还有前向安全性，及时偷走了服务器上的主密钥，你也破解不了历史的加密包。
|
 |
zwh2698Jan 14, 2019 via Android
22
你的安全性不如 https，这种安全设计没法拿出手，即便模拟，建议先看看 https 握手都干了啥，为啥要 pre/master key, 等机制。建议不要自己造安全性不高的轮子，会让自己陷入误区的。检验思考的全面性要借助工具 STRIDE 模型。
|
Select Language