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

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 是一种我们不希望看到的、不得已的做法，因此在此讨论一种更理想的可能性。

Technetiumer

2016-10-19 17:14:08 +08:00

重点是，运营商缓存不可控，不可信。中间路由不可控，不可信。

如果 CDN 作恶，一样给你插广告，盗取数据，但是我可以选择一个不作恶的 CDN 。
如果主机商作恶，一样给你插广告，盗取数据，但是我可以选择一个不作恶的主机商。

运营商 / 中间路由怎么办？给你插广告，盗取数据，怎么办？换中间路由？？？

jybox

2016-10-19 21:38:34 +08:00

@skydiver Cache-Control 中的 public 和 private 就用于表示任何人都可以缓存，还是只有浏览器可以缓存。
@msg7086 运营商不是有很多可以在 HTTP 请求中加广告的中间节点么，这些节点就是有能力解析 HTTP 的，加点存储就可以做缓存了。
@bumz 如果是 HTTPS 的话也可以随机地干扰请求造成同样的效果。当然，攻击者可以针对性地干扰特定内容，使这些内容无法被获取，这个确实是个问题。
@Technetiumer 我已经说过了前提是不包括用户数据的资源，按照我的想法，浏览器在收到校验和错误的资源后确实应该拒绝显示和执行（ Subresource Integrity 也是这样要求的，见主贴的附言），对于 HTTPS 连接，攻击者可以随机地干扰请求，造成的效果其实是一样的（一些资源无法被获取），从这个角度来说， HTTPS 也不能防篡改呀。
@Technetiumer CDN 的问题在于即使 Google 配置了很多 CDN ，仍然有代理存在的空间（我并不是说不用 CDN ，而是说 CDN 和代理是互相补充的），但依然不能覆盖到所有的用户，而且 CDN 所处的位置基本上已经在骨干网了，相比于更末端的代理节点的缓存，会占用更多骨干网的资源。
@Technetiumer 我提出的校验和就是为了解决中间节点不可信的问题呀，其实这和 HTTPS 区别不大。如果 HTTPS 是一个小众的东西，那么运营商当然可以肆无忌惮地干扰 HTTPS 连接，迫使你换回可以插广告的 HTTP ，但现在 HTTPS 已经是大势所趋了，所以运营商不敢这么做了。同样的，如果校验和变成一项普遍使用的技术，那么运营商也不敢去通过插广告的方式干扰校验和的工作 —— 因为这样的结果是网页显示不出来，用户会来投诉。

jybox

2016-10-19 21:42:06 +08:00

@shyling 我还是本着能省一点是一点的想法（不过确实有人指出，这种想法会令技术上的复杂度增加，反而需要花费更多的资源在软件开发上）。另一方面是现在网络的延时已经很接近物理极限了，比如中美的延迟极限就是 130ms 左右了，不可能再优化了，而通过代理节点的缓存就可以在一些情况下省掉这个延迟，还是有一定价值的。
@liwanglin12 不是很多网站都会在静态资源的 URL 里加版本来辅助刷新缓存嘛，这种做法可以保留呀。

jybox

2016-10-19 21:44:15 +08:00

@Technetiumer 抱歉 67 楼语序有点错乱，应为： CDN 的问题在于即使 Google 配置了很多 CDN ，但依然不能覆盖到所有的用户，仍然有代理存在的空间（我并不是说不用 CDN ，而是说 CDN 和代理是互相补充的），而且 CDN 所处的位置基本上已经在骨干网了，相比于更末端的代理节点的缓存，会占用更多骨干网的资源。

msg7086

2016-10-20 00:05:21 +08:00

@jybox
#67 加存储的中间节点已经有人实现了，劫持用户请求然后跳转到缓存服务器。
然而缓存服务器上的缓存刷新有问题会导致比如说你请求的是新版软件，返回旧版软件。
而且中间节点如果作恶，你是没有办法监管或者防御的。

#68 能省一点就省一点是没错，现在互联网也是朝这个方向在走的。
你说要省掉中美之间的延迟，对，这个就是 CDN 的用武之地，和中间节点没有一毛钱的关系。
#69 里提到的 Google ，我可以告诉你，全世界没有什么地方是 Google CDN 覆盖不到的。
我就拿我手里的机器测一下到谷歌的速度好了。
俄罗斯 20ms
美东 18ms
美西 1ms
加拿大 22ms
立陶宛 25ms
日本 17ms
你给我举个不能覆盖的例子？大概只有南极科考站了吧。

你可能要提中国。不过中国也是有 Google CDN 的，只不过有关部门表示这是违禁的，不许开罢了。
所以就算你让中间节点去缓存 Google 的资源，结果也只是负责人去坐牢。

lightening

2016-10-20 16:57:54 +08:00

我觉得楼上不少人没明白楼主想表达什么意思。

说 HTTPS 的页面中的 HTTP assets 不会被加载，或者浏览器会警告的，搞错了因果关系。浏览器会警告“不安全”是因为这样确实不安全，但是我们如果用另一种方法来替代全站 HTTPS ，但仍然确保安全性的话，浏览器的作者自然会取消这个警告。

至于运营商替换内容，只要有 digest 在，浏览器一旦检测到内容被替换，就可以拒绝显示页面。这样运营商的劫持行为就会导致网站彻底不可用。用户只能选择要么去投诉，要么不上这个网站。