
1 alvin666 2019-01-13 17:54:32 +08:00 via Android 这不就是自己实现了 https ? |
2 chendy 2019-01-13 17:56:26 +08:00 所以为啥不用 https 呢 |
3 tomczhen 2019-01-13 17:56:32 +08:00 有种技术叫 HTTP 双向认证,了解一下? |
4 ayase252 2019-01-13 17:59:32 +08:00 via iPhone 加上证书验证差不多就是 HTTPS 了啊 |
5 yuikns 2019-01-13 18:01:27 +08:00 via iPad jwt 和此处有什么关系……? |
6 des 2019-01-13 18:02:05 +08:00 via Android 所以为什么不用 https ??? |
7 weizhen199 2019-01-13 18:02:49 +08:00 https api 除了抗重放以外还差什么吗 |
8 Immortal 2019-01-13 18:03:18 +08:00 所以为什么不用 https+jwt |
9 yuikns 2019-01-13 18:03:23 +08:00 via iPad 现在还有人分不清 Password 和 Encryption ? |
11 chinvo 2019-01-13 18:43:15 +08:00 via iPhone 你这和 HTTPS 有啥区别 |
12 xiangyuecn 2019-01-13 18:52:46 +08:00 @weizhen199 #7 你的意思 https 包能重放? https 原生抗重放吧 |
13 masker 2019-01-13 19:02:31 +08:00 重定义 HTTPS ? |
14 lhx2008 2019-01-13 19:04:28 +08:00 via Android 有鬼用,没有证书验证是否服务器是服务器发出的公钥,第三人半路拦截就可以发一个他自己的公钥了。完全不可靠。 |
15 lhx2008 2019-01-13 19:08:33 +08:00 via Android @xiangyuecn https 应该不能抗重放吧,还是可以重发加密包的 |
16 xiangyuecn 2019-01-13 19:46:45 +08:00 @lhx2008 我觉得除了明文外,重放是最恶劣的底层协议缺陷。如果 https 能重放,那比 http 优越不到哪去,还不如回滚到大家都用 http 的时代,轻快省力,就是裸奔了点。重发≠重放,服务器收到这种包直接丢弃好像。 |
17 yzwduck 2019-01-13 19:57:16 +08:00 @lhx2008 在正常密钥交换的情况下,HTTPS ( TLS 本身)就抗重放。重发的包不会影响上层应用数据内容,最多服务器认为协议异常而终止连接。 https://security.stackexchange.com/q/20105 |
18 lhx2008 2019-01-13 20:04:28 +08:00 via Android @xiangyuecn @yzwduck 谢谢,确实,中间人无法重发 TCP 包来做重放攻击,但是业务上还是得做随机数来防止在客户端上的重发。还有一种比较高成本的第三人攻击是可以通过中断 TCP 回程,迫使客户端重发。 |
20 jimrok 2019-01-13 21:09:43 +08:00 @lhx2008 https 无法重放,https 的握手建立过程中,server 决定每次的交换密钥,所以,无法回放加密的包来建立握手。另外 https 还有前向安全性,及时偷走了服务器上的主密钥,你也破解不了历史的加密包。 |
21 xuanbg 2019-01-14 01:00:53 +08:00 @chinvo 不一样,HTTPS 使用的是 SSL 隧道,他这个是一次性密钥加密。效果一样,但开销比较大,每次都要用 RSA 加密和解密。 |
22 zwh2698 2019-01-14 09:04:46 +08:00 via Android 你的安全性不如 https,这种安全设计没法拿出手,即便模拟,建议先看看 https 握手都干了啥,为啥要 pre/master key, 等机制。建议不要自己造安全性不高的轮子,会让自己陷入误区的。检验思考的全面性要借助工具 STRIDE 模型。 |