我们真的有必要全站 HTTPS 么?

2016-10-18 22:12:44 +08:00
 jybox

SSL 同时保证了数据不被窃听和不被篡改,但也导致了通过 HTTPS 的请求无法被网络中的代理节点缓存 —— 缓存和代理本来是 HTTP 中协议中很重要的部分,但如果使用 HTTPS ,中间节点连 HTTP 头都读不到。

对于包含用户数据的请求用 HTTPS 我觉得是没有问题的;但其实更多的请求是图片、样式表和脚本,这些请求 只需要防篡改,而不需要防窃听,因此完全没有必要使用 SSL 。

我觉得更好的方式是通过 HTTPS 发送主页面,主页面中包含了所有引用的资源的校验和,然后被引用的资源以 HTTP 传输,可以被网络中的代理节点缓存(例如运营商可以在小区的出口路由处部署一个带缓存功能的代理,可节省很多骨干网的带宽),然后浏览器收到资源后检查校验和,确保资源没有被篡改。

<script src='scripts.js' sha256-checksum='e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'></script>

<img src='logo.png' sha256-checksum='cd372fb85148700fa88095e3492d3f9f5beb43e555e5ff26d95f5a6adc36f8e6' />

其实这就像很多 Linux 发行版的仓库一样,包本身有单独的 GPG 签名来防篡改,因此文件本身可以通过 HTTP 传输,也可以被代理和缓存。但是现在有一些源都支持 HTTPS 了,感觉很是浪费资源呀,也增加了用户可以感受到的延迟。

当然,我也很清楚现在 HTTPS 的大势所趋很大原因是因为运营商不按照规则去做缓存,但我觉得全站 HTTPS 是一种我们不希望看到的、不得已的做法,因此在此讨论一种更理想的可能性。

14623 次点击
所在节点    SSL
84 条回复
JJaicmkmy
2016-10-18 22:17:25 +08:00
但是 HTTPS 页面中包含 HTTP 的图片是会有感叹号 Warning 的。
JJaicmkmy
2016-10-18 22:17:58 +08:00
而且 HTTPS 页面中的 HTTP 的脚本是不会运行的。
zsx
2016-10-18 22:19:25 +08:00
用 https 一个重要的理由是大部分浏览器都不支持非 https 的 HTTP/2 协议,以及防止 MITM 和 Sniffer
czb
2016-10-18 22:20:28 +08:00
1.SSL 不会对缓存带来问题 中间节点只要有证书便可以轻松实现缓存
2.checksum
pmpio
2016-10-18 22:20:35 +08:00
你这想法有个问题,如果中间的劫持者纯粹是捣乱,就算自己修改的资源无法被用户显示也要故意修改,那么,你们网页上要么不停地重复下载那些图片、脚本类的资源,要么显示大片空白,反正肯定无法显示你原本的资源, http 劫持就有那么牛 B 。。。
czb
2016-10-18 22:21:56 +08:00
防篡改的话如果浏览器发现 checksum 不对便会拒绝加载那个资源,会导致页面不完整
所以针对你说的问题 SSL 都是较好的解决方案
soland
2016-10-18 22:23:22 +08:00
你以为图片就没人劫持了吗?统统给你换成广告。
xxxyyy
2016-10-18 22:23:57 +08:00
w3 已经有一个类似的,叫 subreouce integrity
xxxyyy
2016-10-18 22:25:21 +08:00
@xxxyyy s/subreouce/subresource
21grams
2016-10-18 22:25:30 +08:00
有必要
czb
2016-10-18 22:25:34 +08:00
如果所说的是运营商缓存 我只能说运营商缓存自己很难控制 缓存策略什么的都没有公开 而且那么多运营商(甚至小区出口)难以控制文件版本 而且部分运营商的缓存时间是忽略 header 的过期时间的 所以为了提供一致的客户体验 最起码我是抵制运营商缓存的
jybox
2016-10-18 22:27:38 +08:00
@JJaicmkmy @zsx 所以说这是我不希望看到的呀(浏览器强制我们使用 HTTPS )
@czb HTTPS 的中间节点(代理)连 URL 都读不到呀
@pmpio @czb 其实是一样的,如果有人干扰所有的 HTTPS 连接的话,一样加载不出来。当然,改成 HTTP 的话,中间人就知道被请求的 URL 了,可以针对性地做干扰。
czb
2016-10-18 22:35:08 +08:00
@jybox
1.自己部署或者用第三方的 CDN 都是可以的,这个是已经大规模使用的
2.退一步说 你这种说法也没错 但是 HTTP 可以更加针对性的干扰(路径 文件名 后缀)但是 HTTPS 不行 而且如果图片里面是有你的私人相片 你会希望被缓存在一个公开服务器吗 而且现在多加密一个文件所用的时间和资源基本可以忽略不记 何苦呢
rainfox
2016-10-18 22:41:46 +08:00
然而,CDN 现在不少都可以支持 https 了,然后说速度慢的难道不知道 HTTP/2 更快吗?
tenca
2016-10-18 22:44:42 +08:00
我觉得楼主没有完全理解 HTTPS 的意义何在。
jigloo
2016-10-18 22:49:01 +08:00
只看了一眼,毛病太多。挑两个说下

1. css/js/image 这些可以边下载变渲染(显示),你这个就不行。
2. http code 的 3xx/4xx/5xx 的语义也没法支持了。
wevsty
2016-10-18 22:50:38 +08:00
已经完成 SSL/TLS 握手以后 HTTPS 的开销并不比 HTTP 多很多,为什么要舍近求远抛弃 HTTPS 方案自己写校验?
CloudnuY
2016-10-18 23:10:20 +08:00
永远想不到运营商有多么恶心的方法去劫持
msg7086
2016-10-18 23:17:35 +08:00
@jybox
「 HTTPS 的中间节点(代理)连 URL 都读不到呀 」
「 SSL 不会对缓存带来问题 中间节点只要有证书便可以轻松实现缓存」

人家都告诉你了还要坚持己见?
jybox
2016-10-18 23:37:53 +08:00
@msg7086 HTTPS 的中间节点能读到请求内容岂不成了中间人攻击了?我相信 @czb 的意思是可以配置一个有独立的域名和证书的 CDN 来加快资源的获取,但这个过程不是透明的,网站所有者需要去配置 CDN 、更新网站上所引用的资源地址。

而我的意思是说如果我到一个网站的 HTTP 请求经过了若干个路由器或 HTTP 代理,那么其中任何一个路由或代理如果有能力解析 HTTP 的话,都可以按照 HTTP 的缓存规则(例如 cache-control: public )去做缓存而不是继续转发请求,这个行为对用户和网站所有者都是透明的,这在 HTTPS 是做不到的。

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

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

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

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

© 2021 V2EX