❗ 本文最后更新于 3108 天前,文中所描述的信息可能已发生改变,请谨慎使用。
关于「启用 HTTPS 的经验分享」这个话题,我已经写过两篇文章:第一篇主要介绍 HTTPS 如何与一些较新的安全规范配合使用,面向的是现代浏览器;第二篇主要讨论启用 HTTPS 过程中,在 SSL 版本、Cipher Suite、证书、SSL 扩展(如 SNI)等方面可能遇到的问题,以及在老旧浏览器下如何取舍。本文做为本系列最后一篇,我想补充一些启用 HTTPS 过程中的注意事项。
资源替换
HTTPS 网页中加载的 HTTP 资源被称之为 Mixed Content(混合内容),我在之前的文章中详细介绍了 Optionally-blockable
和 Blockable
两类 Mixed Content,也介绍了各种浏览器对 Mixed Content 的加载策略。为了最好的用户体验,HTTPS 网站不要出现任何 Mixed Content。换句话说,HTTPS 页面中所有资源都必须替换为 HTTPS 的。
代码层的替换比较简单,但一些存在数据库中的文本(例如商品描述中的图片地址)就很容易遗漏,需要特别注意。
如果你的网站只打算支持 HTTPS,将所有外链资源(CSS、JS、图片、音频、字体文件、异步接口等等)直接替换为 HTTPS 地址,再把网站 HTTP 请求重定向到 HTTPS 即可。
当前很多支持 HTTPS 的网站出于各种原因,针对老旧浏览器或特殊网络还是允许通过 HTTP 访问。这时候,强烈建议让所有资源服务都同时支持 HTTP/HTTPS 访问。这样只要页面在使用这些资源时省略协议部分,浏览器就能根据主页面协议类型来自动选择 HTTP/HTTPS 资源。例如:
<img src="https://example.com/static/img/blog/ququ.jpg" />
=>
<img src="//example.com/static/img/blog/ququ.jpg" />
针对现代浏览器,还可以通过 upgrade-insecure-requests
这个 CSP 指令,让浏览器自动替换。更多说明,详见这里。
省略 URL 协议有个风险点:个别移动网络提供商篡改页面时,会将这种写法的 URL 改坏,导致资源无法访问。详见《诡异问题排查之「DataURI 引发的血案」》这篇文章。
服务端代理
在启用 HTTPS 的实际过程中,本站的静态资源和接口相对容易改造,毕竟都可控。但很多第三方资源或接口就是不提供 HTTPS,那就只能在服务端做一层 HTTPS 代理。
服务端代理另外一个典型应用是用来解决跨域问题。通常代理本身要做的工作不多,直接用 Nginx 做反向代理,或者用 Lua、Node.js 等语言构建轻量中转服务都是不错的选择。但也有几点需要注意:
- 代理对请求 Referrer、被代理的 URL 都需要做好白名单机制;
- 代理会造成第三方通过
REMOTE_ADDR
拿到的是代理 IP,很可能导致这个 IP 被限制请求频率或被封; - 代理只能拿到自己域名下的 Cookie,需要从其它域获取 Cookie 的第三方接口被代理后可能不能正常工作;
另外,对于页面上通过 iframe 嵌入的第三方 HTTP 页面,如果要做 HTTPS 代理,还需要修改页面里的所有资源链接,很容易出问题。对于这种情况,强烈建议联系第三方修改或者换产品方案,不要在 HTTPS 代理上耗费太多精力。
还有一个不那么常见的问题顺便说下:如果页面表单的 action
地址使用了 HTTP 地址,会导致 Chrome 地址栏绿色小锁消失。下面是一个简单示例:
<form action="http://imququ.com"></form>
最后,再讨论一个第三方接口由本地服务提供的特殊场景(例如 Android APP 在本地开一个 127.0.0.1 的 HTTP 服务,给网页调用)。这个服务几乎不可能升级为 HTTPS,显然也无法使用服务端代理。对于这个问题,我在《利用图片传输数据的另类思路》这篇文章里,提供了一种能用但不完美的解决方案。
Referrer
目前大部分浏览器,在发生协议降级时默认不发送 Referrer 信息,最典型的场景就是从 HTTPS 页面点链接跳到 HTTP 网站时,浏览器并不会在请求头中带上 Referer 字段。对于给第三方导流的网站,这一点肯定无法接受。
针对现代浏览器,这个问题可以通过给页面加上下面这个 meta 标签来解决:
<meta name="referrer" content="always" />
有关这个 meta 的更多用法,请参考《Referrer Policy 介绍》这篇文章。
针对老旧浏览器,这个问题可以通过在本站部署 HTTP 跳转服务来解决,借助 HTTP 页面把 Referrer 传给第三方。
另外,本文同时出现了 Referrer
和 Referer
两种写法,如果对此有困惑,推荐阅读《Referrer 还是 Referer?》。
连通性
很多网站在启用 HTTPS 之后,都会接到无法访问的用户反馈。除去自身配置问题(我在《从启用 HTTP/2 导致网站无法访问说起》一文中列举了常见的配置错误)之外,很有可能是 HTTPS 连通性受到了干扰。
最常见的干扰是运营商劫持了域名 DNS 解析,这种劫持服务器一般会将用户请求反代到源网站,再在响应里夹带私货。在 HTTP 时代,这种劫持多半只会造成页面出现广告,网站还能用;而升级到 HTTPS 后,由于身份认证机制的存在,劫持服务器无法成功反代第三方网站(成功实施 HTTPS 中间人攻击的条件请看《三种解密 HTTPS 流量的方法介绍》),从而导致网站完全不可用。
我们最近在移动端做过一个统计:对比在 HTTP 网站加载本域 HTTP/HTTPS 空图片的失败率(我们对失败的定义是触发图片的 error 事件,或者超过 9s 仍未触发 load 事件),HTTPS 要高出三个百分点。
对于 HTTPS 请求失败日志,还可以进一步分析,比如找出是哪些运营商 / 地域的 HTTPS 联通性比较差,从而有针对性做一些策略。由于每个业务情况都不相同,这里只抛出问题,详细的统计数据和应对措施不在这里讨论。
本文先写到这里,有新的注意事项我会随时补充进来。最后我想说的是,启用 HTTPS 并不复杂,虽然会遇到各种各样的问题,但都能找到对应的解决方案,所需的无非就是决心、耐心和细心。在现代浏览器中,越来越多的新功能都限定在 HTTPS 下才能使用,HTTPS 也是部署 HTTP/2 的先决条件。HTTPS 和 HTTP/2 已经成为 WEB 服务的标配,赶紧行动起来吧。
本文链接:https://imququ.com/post/sth-about-switch-to-https-3.html,参与评论 »
--EOF--
发表于 2016-05-05 00:11:16,并被添加「HTTPS」标签。查看本文 Markdown 版本 »
专题「HTTP 相关」的其他文章 »
- 记一次图片访问异常排查过程 (Apr 28, 2023)
- HTTP Alternative Services 介绍 (Aug 21, 2016)
- 如何压缩 HTTP 请求正文 (Apr 18, 2016)
- HTTP 协议中的 Content-Encoding (Apr 17, 2016)
- 三种解密 HTTPS 流量的方法介绍 (Mar 28, 2016)
- HTTP Public Key Pinning 介绍 (Mar 05, 2016)
- 关于启用 HTTPS 的一些经验分享(二) (Dec 22, 2015)
- 关于启用 HTTPS 的一些经验分享(一) (Dec 04, 2015)
- HTTP 代理原理及实现(二) (Nov 20, 2015)
- HTTP 代理原理及实现(一) (Nov 20, 2015)
Comments
Waline 评论加载中...