转载-如何正确使用HTTPS加密协议经验分享(三)

关于「如何正确使用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 地址栏绿色小锁消失。

最后，再讨论一个第三方接口由本地服务提供的特殊场景(例如 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 之后，都会接到无法访问的用户反馈。除去自身配置问题之外，很有可能是HTTPS 连通性受到了干扰。

最常见的干扰是运营商劫持了域名DNS 解析，这种劫持服务器一般会将用户请求反代到源网站，再在响应里夹带私货。在HTTP 时代，这种劫持多半只会造成页面出现广告，网站还能用;而升级到HTTPS 后，由于身份认证机制的存在，劫持服务器无法成功反代第三方网站，从而导致网站完全不可用。

我们最近在移动端做过一个统计：对比在HTTP 网站加载本域HTTP/HTTPS 空图片的失败率(我们对失败的定义是触发图片的error 事件，或者超过9s 仍未触发load 事件)，HTTPS 要高出三个百分点。

对于HTTPS 请求失败日志，还可以进一步分析，比如找出是哪些运营商 / 地域的 HTTPS 联通性比较差，从而有针对性做一些策略。由于每个业务情况都不相同，这里只抛出问题，详细的统计数据和应对措施不在这里讨论。

本文先写到这里，有新的注意事项我会随时补充进来。最后我想说的是，启用HTTPS 并不复杂，虽然会遇到各种各样的问题，但都能找到对应的解决方案，所需的无非就是决心、耐心和细心。在现代浏览器中，越来越多的新功能都限定在HTTPS 下才能使用，HTTPS 也是部署HTTP/2 的先决条件。HTTPS 和HTTP/2 已经成为WEB 服务的标配，赶紧行动起来吧。

相关阅读：

如何正确使用HTTPS加密协议经验分享(一)

如何正确使用HTTPS加密协议经验分享(二)

文章来源：https://imququ.com/post/sth-about-switch-to-https-3.html

沃通CA为广大用户提供安全可信,性价比高的EV SSL证书,OV SSL证书,IV SSL证书以及免费SSL证书,欢迎申请体验!申请地址：http://www.wosign.com