针对下载看了 HTTPS 还是放弃

2017-08-03 05:28:07 +08:00
 tangren
刚刚测试下 https 下载和 Http 下载速度对比。同站点单线程下载速度 https 只有 http 的 30%左右,看来 https 有些情况下还是不要应用
14266 次点击
所在节点    程序员
82 条回复
LeoEatle
2017-08-03 17:14:08 +08:00
说真的,要不是现在 ISP 技术不高超,你敢用 HTTP 我可以劫持到 P 图片再备份到另一个系统,各种监视全都能做
sgissb1
2017-08-03 17:29:59 +08:00
@SmashPHP 小朋友,不懂要学。静态破解这个字眼你要注意看。你把我弄笑喷了。
HarrisonZ
2017-08-03 17:30:03 +08:00
都直接 http/2 了,还用 http 的不嫌慢吗
sgissb1
2017-08-03 17:31:18 +08:00
@SmashPHP 当然从你只会说 socket 这个字眼来看,你应该是不了解比 socket 更底层的。下次出来喷人,麻烦搞懂了再来说。^_^
zpf124
2017-08-03 17:32:06 +08:00
@sgissb1 哪有那么容易,
现在想要劫持 https 页还行得通的主要就是中间人, 在你首次访问域名时,先 dns 解析到中间人的网站上,然后中间人相当于正向代理你的访问 去该发 https 请求。实际 是 用户 http -> 中间人 -> https 站点。

而且现在这个问题也有了一些解决方案了,就是 [hsts preload list]( https://hstspreload.org/), 目前正在普及,几大浏览器厂商都支持了,处理方案就是缓存一个 hsts 列表,在用户访问列表内的网站时,直接强制使用 https,中间人又不可能拥有合法的证书。

到这种地步了 中间人要再想劫持 那他就得学学 阿里 和 12306 诱导用户安装 rootCA 了。
panda1001
2017-08-03 17:38:39 +08:00
没有在腾讯云备案的域名 http 访问非 80 端口也会被拦截,而 https 就没事,做个测试也拦截真是醉了
sgissb1
2017-08-03 17:59:53 +08:00
@zpf124 https 也不是不能劫持,确实大多数办法都是中间人的方式。不过也要看配置,如果有傻鸟配置了对称加密,或者不重新交换证书的情况下,一般长连就容易出事了。

我们以前是做边缘设备的,就有傻逼用户这样干过。最后我们部门还差点背黑锅。。。。。不过我们是仅仅针对 ssl 通讯,这个比 https 来说广泛多了。毕竟 https 本质也只是 http+ssl,上面玩在多花样也本质变不了。

所以这事吧。。。。。还真因为我曾经的工作关系。。。。。我知道一些。

不过对于连接时间比较短的连接,并且密钥更新周期相对长一点的情况,还是可以破,只是难度较大。某些特定网络下,就算连接时间短,就算是非对称定时更新密钥的情况,破还是有希望的(非中间人)。

破解 ssl 通讯的办法其实业内都知道,只不过由于协商好了私钥之后,由于定期更新了私钥,所以导致破解难度加大(这里不包含暴力破解)。只要拿到双方的解密私钥,还是有希望的。不过没有亲自试验过(没那个能耐,当时我们有个大神玩过友商的设备,还写了个工具模拟正常通讯)。

至于“数据搬运工”们来说,要拿到解密密钥还是并非难事,有了解密的私钥,一样能看到你在干啥,只不过不能插入信息而已(因为没加密密钥)。

说到底也不算安全,真安全是别人解密不开,也加密不进去。
jingniao
2017-08-03 18:29:06 +08:00
http 的运营商劫持啊代理之类,真的很严重,我有时候用 vps 中转下载,电信网 http 绝大多数被重定向到四川的一个机房,文件不一致也不是没遇到过。就算是 https,你服务器配置不对被降级也说不过来
feather12315
2017-08-03 19:25:33 +08:00
对于现代 CPU 来说,加密解密时间可以忽略不计,但在网络传输过程中的确增加了一些开销。比如目前最常见的 AES-128-GCM,GCM 用于认证,类似于 hash 函数的机制,把那一块数据映射为定长的 hash 值,用以保证所传输的数据不被篡改
zpf124
2017-08-03 19:58:00 +08:00
@sgissb1 对于你们设备的 ssl 不太懂,你们设备应该没有证书合法性的校验吧。

https 的证书 需要 rootCA 颁发的,rootCA 相当于 顶级的担保人,都是内置到各个操作系统中的,这部分 rootCA 对那些证书颁发机构担保,再由证书颁发去给对下面的域名证书做担保。

每次浏览器用 https 时都会根据网站发过来的证书,按照 rootCA -> ca -> 网站证书 的顺序一级一级询问下一级证书是否合法。

而且传输过程必须使用不对症加密, 网站私钥是不会让外人知道的。
sgissb1
2017-08-03 22:37:48 +08:00
@zpf124 设备是边缘设备。。。。干嘛检测呢,我们本来就是有功能要做审计的,需要。。。。那啥。
lyhiving
2017-08-03 22:48:22 +08:00
如果是支付或者下载 apk 这种,必须 HTTPS。
FrankFang128
2017-08-03 23:23:54 +08:00
你这么在意速度,就不应该用 HTTPS。
等你在意安全&防篡改的时候再考虑 HTTPS。
msg7086
2017-08-04 00:04:18 +08:00
@honeycomb 回复上下文「反驳理智论」说的是不启用 HTTPS 后会被劫持的情况。
wwqgtxx
2017-08-04 10:09:07 +08:00
@sgissb1 单纯的 SSL 通讯是很容易被中间人的,所以 SSH 才会在发现连接的服务器 SSL 证书指纹不一样的时候让你确认是不是合法的服务器,只不过大部分人都无脑的点 YES 而已。而 HTTPS 的安全性在 SSL 的基础上增加了基于证书链的机制,使得除非你能控制证书颁发机制,否则没有那么容易中间人
而对于传输过程中的秘钥破解问题,你是觉得 AES 的加密真的就那么不堪一击么,要是 AES-256 能那么容易破解,那 HTTPS 还有什么推进的必要
真正在 HTTPS 通讯中只有在交换对称加密秘钥的时候才是用非对称的方式加密,后面还是用协商好的秘钥进行对称加密的,一般都是 AES 家族或者是 CHACHA20 系列,你该不会以为真正的通讯过程中一直在用他们最初交换的非对称秘钥进行数据加密解密吧
tangren
2017-08-04 10:09:27 +08:00
@whileFalse 100M 1T 10T 都试过
tangren
2017-08-04 10:13:10 +08:00
@momocraft 理论上多了好几次握手解密等.
momocraft
2017-08-04 10:17:06 +08:00
@tangren 这些都发生在 ssl 通道建立之前而且流量不大时间不长,在长时间连接时对平均速度的影响应该有限。所以我说问的是 "测过"
lslqtz
2017-08-04 15:16:37 +08:00
@SmashPHP 这里说的是 HTTPS,不是 HTTP。
@honeycomb 你说的情况撑死 CDN,运营商基本没有可能会有。
"运营商的流量过滤设施里有上级证书"
如果运营商的流量过滤设施不仅有上级证书还有对应的 CA 私钥的话这家 CA 早倒闭了
honeycomb
2017-08-04 15:24:07 +08:00
@lslqtz
这种事情(防火墙内置 ca 的情况)据说在一些企业内有出现,当然也可能是企业的私有 ca/自签名证书的形式

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/379987

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX