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

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

感谢 @xxxyyy 指出 Subresource Integrity 已进入 Recommendation 状态，并且已在 Chrome 45 中被支持； GitHub 也为来自 CDN 的资源添加了校验和，可在 GitHub 主站页面代码中搜索 integrity 。

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
http://githubengineering.com/subresource-integrity/

[JJaicmkmy]

但是 HTTPS 页面中包含 HTTP 的图片是会有感叹号 Warning 的。

[JJaicmkmy]

而且 HTTPS 页面中的 HTTP 的脚本是不会运行的。

[zsx]

用 https 一个重要的理由是大部分浏览器都不支持非 https 的 HTTP/2 协议，以及防止 MITM 和 Sniffer

[czb]

1.SSL 不会对缓存带来问题 中间节点只要有证书便可以轻松实现缓存
2.checksum

[pmpio]

你这想法有个问题，如果中间的劫持者纯粹是捣乱，就算自己修改的资源无法被用户显示也要故意修改，那么，你们网页上要么不停地重复下载那些图片、脚本类的资源，要么显示大片空白，反正肯定无法显示你原本的资源， http 劫持就有那么牛 B 。。。

[czb]

防篡改的话如果浏览器发现 checksum 不对便会拒绝加载那个资源，会导致页面不完整
所以针对你说的问题 SSL 都是较好的解决方案

[soland]

你以为图片就没人劫持了吗？统统给你换成广告。

[xxxyyy]

w3 已经有一个类似的，叫 subreouce integrity

[xxxyyy]

@xxxyyy s/subreouce/subresource

[21grams]

有必要

[czb]

如果所说的是运营商缓存 我只能说运营商缓存自己很难控制 缓存策略什么的都没有公开 而且那么多运营商（甚至小区出口)难以控制文件版本 而且部分运营商的缓存时间是忽略 header 的过期时间的 所以为了提供一致的客户体验 最起码我是抵制运营商缓存的

[jybox]

@JJaicmkmy @zsx 所以说这是我不希望看到的呀（浏览器强制我们使用 HTTPS ）
@czb HTTPS 的中间节点（代理）连 URL 都读不到呀
@pmpio @czb 其实是一样的，如果有人干扰所有的 HTTPS 连接的话，一样加载不出来。当然，改成 HTTP 的话，中间人就知道被请求的 URL 了，可以针对性地做干扰。

[czb]

@jybox
1.自己部署或者用第三方的 CDN 都是可以的，这个是已经大规模使用的
2.退一步说 你这种说法也没错 但是 HTTP 可以更加针对性的干扰(路径 文件名 后缀)但是 HTTPS 不行 而且如果图片里面是有你的私人相片 你会希望被缓存在一个公开服务器吗 而且现在多加密一个文件所用的时间和资源基本可以忽略不记 何苦呢

[rainfox]

然而,CDN 现在不少都可以支持 https 了，然后说速度慢的难道不知道 HTTP/2 更快吗？

[tenca]

我觉得楼主没有完全理解 HTTPS 的意义何在。

[ldbC5uTBj11yaeh5]

只看了一眼，毛病太多。挑两个说下

1. css/js/image 这些可以边下载变渲染（显示），你这个就不行。
2. http code 的 3xx/4xx/5xx 的语义也没法支持了。

[wevsty]

已经完成 SSL/TLS 握手以后 HTTPS 的开销并不比 HTTP 多很多，为什么要舍近求远抛弃 HTTPS 方案自己写校验？

[CloudnuY]

永远想不到运营商有多么恶心的方法去劫持

[msg7086]

@jybox
「 HTTPS 的中间节点（代理）连 URL 都读不到呀 」
「 SSL 不会对缓存带来问题 中间节点只要有证书便可以轻松实现缓存」

人家都告诉你了还要坚持己见？

[jybox]

@msg7086 HTTPS 的中间节点能读到请求内容岂不成了中间人攻击了？我相信 @czb 的意思是可以配置一个有独立的域名和证书的 CDN 来加快资源的获取，但这个过程不是透明的，网站所有者需要去配置 CDN 、更新网站上所引用的资源地址。

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

[jybox]

@jigloo CSS 和 JS 按我的理解应该是不能边下载边执行的，图片的话确实是一个问题（估计这也是 Subresource Integrity 只支持了 script 和 link 的原因，见我在主贴上的附言）。缓存和代理应该尊重 HTTP 中代理相关的头，这本来就是 HTTP 标准的一部分，并不会影响语义。
@wevsty 我是希望浏览器能够支持校验和，前面有人指出有个叫 Subresource Integrity 的特性提供了非常类似的功能，链接见我主贴上的附言。

[ldbC5uTBj11yaeh5]

@jybox

1. css/js 你的理解不对。
2. 在互联网谈尊重标准，这思路太过清奇。套用一句话，“假如标准有用，那么要 SSL 干嘛？”

[xbb7766]

恩，用 http 然后在淘宝上买什么不可描述的东西的话，中间任何一个人都可以获取，要是公司局域网的话，嘿嘿😜……
以及 Checksum 怎么传输？ http?有心想篡改还不是分分钟的事情。

[yidinghe]

签名可以用来防篡改没错。但是如果内容的生成是动态的话，到最后还要给内容加一个签名，非常麻烦。

[yidinghe]

还有一点就是签名只能在篡改事后检查，而 SSL 一开始就防止篡改的发生。要知道运营商篡改内容十分霸道，不会因为你加了签名就不改，改了以后你的资源在页面上无法正常展示，用户并不知道是运营商的原因，还是照样骂你。

[jybox]

@jigloo SSL （ TLS 和 PKI ）不也是一个标准嘛，如果客户端不遵守标准去校验证书、如果 CA 不遵守标准（规则）去给网站签发证书、如果浏览器和操作系统不去审查 CA ，那 SSL 同样没有可靠性可言。

[Osk]

宽带运营商缓存背锅:
1. HTTP 被跳到某 ISP 的 ip 然后来个 404, HTTPS 正常。
2. 下个 exe 居然没数字签名?! 上 vps 下载一查,数字签名正常。从此再也不敢乱用软件的在线更新,宁可手动下载安装, 谁知道软件收到的更新是什么呢?万一没验证,管理员权限一跑,拜拜。

从此对非 HTTPS 恐惧了, 有缓存是快,但谁知道有没有乱缓存? 作为用户,我才不管什么浪费带宽.

Subresource Integrity 虽好,但送我个 404 照样不如 HTTPS

[czb]

@jybox 客户端不检查证书？我知道的恐怕只有 360 了（不知道现在如何），其他稍微严谨点的浏览器都会去检查。 CA 不遵守，坦白说这个是问题（不过现在有 CT HPKP ， CA 的滥发成本和风险有点高，不过确实这个是一个问题）。系统不审查 CA 是什么意思？ CA Root 是植入的 所以说真正有可能的是第二点， CA 的规范性。不过你用 JS 也不能解决这个问题啊。。。 JS 方案在没有 CA 担保的情况下 Key-Exchange 的安全性会有问题

[IvanLing]

App Store 审核要求，明年必须支持 https 。

[zrj766]

非 https 弹广告蛋疼啊

[czb]

@czb 忽略我最后一句，串题了。。。。

[skydiver]

HTTP 的缓存规则是给客户端(浏览器)看的，不是给中间节点看的，本来中间节点就不该缓存。

HTTPS 不影响客户端缓存资源

[lslqtz]

css 可以直接将其他元素设为 display:none ，然后覆盖一张图片。
js 这个自然不用多说。
图片的话感觉没什么大问题 虽然也可以改

[monnand]

运营商：对啊对啊，我还能多帮你缓存一份广告，你看！

[lslqtz]

@jybox 你提供给 cdn 证书， cdn 用这个证书做你到用户的加密，然后回源也做加密， cdn 持有证书，就是这样。

[msg7086]

@jybox 中间人攻击的前提是「攻击」。
CDN 本身就应该是用户配置的。
用户配置上私钥的话，中间人缓存是能做到的。
就算不配置私钥，也可以通过两段式加密解决。

至于路由和代理缓存……
对，这才是「中间人攻击」。
HTTPS 就是为了防止这些中间路由和代理窃听数据的。
（我从网站上下载的小黄图，凭什么要给你路由和代理看？
（我下载某某银行的安全控件，凭什么要让移动电信知道？

我猜想你这么说的原因是你认为：
1. 网站管理员不应该负有配置 CDN 的义务；
2. CDN 缓存应该由运营商或者中间路由、代理来做，而且是自动地，和站长无关地做；
3. 静态数据的地址泄露不会影响用户安全。

然而这几种观点和现在互联网上的主流观点是相悖的。

刚刚看到你主题里提到的 Linux 的 GPG 问题。
这你的理解就完全错了。 Linux 的 GPG 根本不是为了解决 HTTPS->HTTP 问题的。
Linux 的 GPG 签名是打包人签名，目的是防止文件在服务器硬盘上被篡改，而不是网络传输过程中被篡改。
和这种机制类似的有代码签名，目的也是防止二进制文件在硬盘上或者安装包里被篡改。
也就是说，他们是没有办法去应用到「网站」上的，因为网站上的文件并不是整个由站长来生成的。

[lslqtz]

@skydiver 中间节点也应该缓存资源，不然要 cdn 何用，直接发个缓存头就行了

[skydiver]

@lslqtz CDN 是经过网站所有者同意的，一个转发的服务，本身既是客户端也是服务端，自然也遵守客户端缓存头。这和运营商不经过同意的缓存是两码事。

[msg7086]

@lslqtz 互联网正常的中间节点都是交换机路由器。
带大块硬盘的所谓「能缓存资源的中间节点」反而是个少见的东西。

[lslqtz]

@msg7086 我以为是 CDN ，不是中间节点。。

[lslqtz]

@skydiver 理解错了

[davidyin]

有必要用全站 HTTPS ，甚至可能的话，要上 HSTS 。

[Eleutherios]

HTTP 缓存的话……当年我用小米的时候想更新一个招行 Android App ，但由于小米的渣缓存策略，下载的死活都是旧版的……之后再未用过小米和招行

[owt5008137]

你知道 https 可以防劫持么？另外 http/2 可以合并 socket 来减少连接数么

[winglight2016]

@czb 现在我们用的 tomcat 服务器，使用 https 后比 http 版本并发数少了很多，本来是 700 左右，结果降到了 200 多，这个并发的性能问题也是要考虑的

[hqfzone]

对大部分站长来说，防运营商劫持是最主要的吧

[abramstyle]

因为 http2 ， 有必要

[czb]

@winglight2016 我们从 10 开始走的全站 SSL 所以真的就没有对比数据了…

[czb]

10 年

[wwek]

http2.0 搭配 https 其实速度更快了

[cnZary]

还需要 hsts

[bombless]

防篡改可以另外加一种机制倒是真的

[hoosin]

不要因为为了使用 https 而去用 https

[bumz]

虽然防窃听不是在所有场合都必要的，但是为了某些特殊的应用场合单独发明一种防篡改不防窃听的机制是没有必要的，人们没有这个需求，相应的方案由于增加了复杂度也难以得到推广。

另外，如果把篡改（任意做不实的更改）的含义推广到服务而不是文件的层面上，不防窃听而防篡改是不可能的。不防窃听只防文件被篡改，攻击者可以选择性地中断服务，换句话说，虽然文件没有被篡改，但是服务被篡改了。

比如一个托管图片的网站，提供的服务是托管图片。如果防篡改而不防窃听，那么攻击者可以选择性地屏蔽被托管的图片，并且让用户以为是托管网站服务质量差，这显然不是图片托管网站希望看到的结果。宁可终止服务，不能背负服务质量差的不实恶名。

[Balthild]

@jybox 中间人攻击……证书都是你自己给中间节点的，首先它连攻击都不能算。

[1f9u4c9k1y0o0u1]

现在运营商 插广告真是丧心病狂

[dangge]

给我校的镜像站上了 https 的原因是: 锐捷会主动缓存热门文件, 然后更新就很尴尬了.
然而锐捷还算有点节操, 不会缓存你的 http 请求(笑

[Technetiumer]

中间路由和代理才是中间人攻击，我完全不信任中间路由，
请问运营商会不会插广告？中间路由会不会盗取数据？
而 CDN 是站长配置的，不信任干嘛要用，难道你不信任你的云服务器么？

另外你的方案只能检测是否被篡改，而不能防止篡改，
篡改了只能拒绝加载，中间路由强插广告怎么办？拒绝加载么？？？
而 HTTPS ，中间路由根本看不到内容，也无法篡改。

还有，中间路由的缓存站长不可控制，经常不遵守 HTTP 头的缓存设置。
如果运营商不作恶，不插广告，遵守协议，提供一个站长平台给站长设置，就像 CDN 和搜索引擎，并且我的网站没有需要防止窃听的敏感信息，这样的免费 CDN 我还是愿意用的，前提是不被篡改，不插广告，遵守协议，可控。

搜索引擎同样不可控，但是提供站长平台，完全遵守 robots.txt ，不作恶，就可控了。
然而在天朝，运营商不作恶是做梦。

[fangjinmin]

非常有必要。

首先安全性，就不用说了。 2048 位以上没有国家级的攻击几乎不可能能成功了。

再说 SEO ， SEM, google 已经将网站的排名算法改了，启用了 SSL 证书的网站的排名将靠前。
而且各大浏览器，都准备将非 https 的网站标注为不安全。

[jasontse]

你以为这个 checksum 值传输的过程很靠谱不会被篡改吗

[Technetiumer]

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

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

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

[dreamwar]

有必要

[dreamwar]

真的 很有必要

[shyling]

然而为什么要被代理节点缓存，未来发展的趋势肯定是向更加高速，更加实时方向发展。
为什么会想着去被莫名其妙的中间代理缓存呢。。

[tSQghkfhTtQt9mtd]

@jasontse
@xbb7766
checksum 的话他说主页面 HTTPS ，所以安全性没问题
但是这就引出来一个问题，你主站更新了一个 js/css 文件和 sum ，然而中间给你缓存的资源不更新你怎么办？用户体验就是你网站挂了

[usedname]

道德有用还用法律干嘛？

[jybox]

@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]

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

[jybox]

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

[enenaaa]

要相信硬件的发展速度， 这点计算量和带宽，过 3 ， 5 年后根本不是事。当然要选最好的方案。

[wql]

你明文传送 integrity 很容易被篡改，这才是最主要的。

[shyling]

@jybox web 端浏览的效果更多的和带宽有关。。

[reus]

https 似乎会被干扰，就算国内也是

[msg7086]

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

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

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

[msg7086]

还有……
「运营商也不敢去通过插广告的方式干扰校验和的工作 —— 因为这样的结果是网页显示不出来，用户会来投诉。」

不要拍脑袋想事情。你看 Google 被全国 Ban 了，用户是去投诉了还是去用百度了？

括弧笑

[zonyitoo]

楼主还是 Naive 了，我们这边试过被联通直接把整个.js 给替换了，或者是强制在页面上放一个占了屏幕 80%区域的大广告图，是插入到 HTML 里面的。简直过分，现在也是全面切到 HTTPS 了

[macroideal]

发现 https 也能被抓包…

[Hardrain]

但 HTTPS 的页面中 HTTP 链接的.css .js 是"高危内容"不会加载……

[lightening]

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

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

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

[lightening]

这个问题的关键应该是中间节点是不是应该负责缓存？

[lightening]

@msg7086

Google 全站 HTTPS 了，也不是一样被屏蔽？

这个和用哪种加密方式没关系。无论是楼主的方案，还是 HTTPS ，都提供一种机制：一旦页面被运营商试图篡改，用户会知道。另外浏览器完全可以实现检测到 digest 不一致就拒绝显示整个页面。

至于用户选择是否容忍运营商的篡改，是另一个问题。 HTTPS 和 digest 都无法解决这个问题。

[msg7086]

@lightening 你回复的是我哪一楼的内容？我有点跟不上对话了。

[lightening]

@msg7086 这一楼：

“不要拍脑袋想事情。你看 Google 被全国 Ban 了，用户是去投诉了还是去用百度了？ ”

[msg7086]

@lightening 我是回复的 「如果校验和变成一项普遍使用的技术，那么运营商也不敢去通过插广告的方式干扰校验和的工作 —— 因为这样的结果是网页显示不出来，用户会来投诉。」 这段话。

事实上很少会有人真的去投诉说网页显示不出来，只会认为是网站自己出了问题。

至于全站 HTTPS ，有一个好处就是可以更好地防止信道侧漏攻击。