为了应对日益猖獗的流量劫持、数据泄漏、钓鱼欺诈等安全问题，越来越多的网站意识到实施HTTPS加密的重要性，HTTPS 通过TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能，可以有效防止数据被查看或篡改，以及防止中间人冒充。使用HTTPS加密协议替代HTTP明文协议，已经成为不争的共识。而如何正确应用HTTPS加密，成为大家更关心的话题。本文分享一些启用HTTPS加密过程中的经验，重点是如何与一些新出的安全规范配合使用。

一、理解Mixed Content

HTTPS 网页中加载的HTTP资源被称之为Mixed Content(混合内容)，不同浏览器对Mixed Content 有不一样的处理规则。

早期的IE

早期的IE 在发现Mixed Content 请求时，会弹出「是否只查看安全传送的网页内容?」这样一个模态对话框，一旦用户选择「是」，所有Mixed Content 资源都不会加载;选择「否」，所有资源都加载。

比较新的IE

比较新的IE 将模态对话框改为页面底部的提示条，没有之前那么干扰用户。而且默认会加载图片类Mixed Content，其它如 JavaScript、CSS 等资源还是会根据用户选择来决定是否加载。

现代浏览器

现代浏览器(Chrome、Firefox、Safari、Microsoft Edge)，基本上都遵守了W3C 的Mixed Content 规范，将Mixed Content 分为Optionally-blockable 和Blockable 两类：

Optionally-blockable 类 Mixed Content 包含那些危险较小，即使被中间人篡改也无大碍的资源。现代浏览器默认会加载这类资源，同时会在控制台打印警告信息。这类资源包括：

·通过<img>标签加载的图片(包括 SVG 图片);

·通过<video> / <audio> 和<source>标签加载的视频或音频;

·预读的(Prefetched)资源;

除此之外所有的Mixed Content 都是 Blockable，浏览器必须禁止加载这类资源。所以现代浏览器中，对于HTTPS 页面中的JavaScript、CSS 等HTTP 资源，一律不加载，直接在控制台打印错误信息。

移动浏览器

前面所说都是桌面浏览器的行为，移动端情况比较复杂，当前大部分移动浏览器默认允许加载所有 Mixed Content。也就是说，对于移动浏览器来说，HTTPS 中的HTTP 资源，无论是图片还是 JavaScript、CSS，默认都会加载。

补充：上面这段结论源自于我大半年前的测试，本文评论中的ayanamist 同学反馈现状已经有所变化。我又做了一些测试，果然随着操作系统的升级，移动浏览器都开始遵循 Mixed Content 规范了。最新测试表明，对于Blockable 类 Mixed Content：

·iOS 9 以下的Safari，以及Android 5 以下的Webview，默认会加载;

·Android 各版本的Chrome，iOS 9+ 的 Safari，Android 5+ 的 Webview，默认不会加载;

一般选择了全站HTTPS，就要避免出现Mixed Content，页面所有资源请求都走HTTPS 协议才能保证所有平台所有浏览器下都没有问题。

二、合理使用CSP

CSP，全称是 Content Security Policy，它有非常多的指令，用来实现各种各样与页面内容安全相关的功能。这里只介绍两个与HTTPS 相关的指令，更多内容可以看我之前写的《Content Security Policy Level 2 介绍》。

block-all-mixed-content

前面说过，对于HTTPS 中的图片等 Optionally-blockable 类HTTP 资源，现代浏览器默认会加载。图片类资源被劫持，通常不会有太大的问题，但也有一些风险，例如很多网页按钮是用图片实现的，中间人把这些图片改掉，也会干扰用户使用。

通过CSP的 block-all-mixed-content 指令，可以让页面进入对混合内容的严格检测(Strict Mixed Content Checking)模式。在这种模式下，所有非HTTPS 资源都不允许加载。跟其它所有CSP 规则一样，可以通过以下两种方式启用这个指令：

HTTP 响应头方式：

Content-Security-Policy: block-all-mixed-content

<meta>标签方式：

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

upgrade-insecure-requests

历史悠久的大站在往HTTPS迁移的过程中，工作量往往非常巨大，尤其是将所有资源都替换为HTTPS 这一步，很容易产生疏漏。即使所有代码都确认没有问题，很可能某些从数据库读取的字段中还存在HTTP链接。

而通过upgrade-insecure-requests 这个CSP 指令，可以让浏览器帮忙做这个转换。启用这个策略后，有两个变化：

· 页面所有 HTTP 资源，会被替换为HTTPS 地址再发起请求;

· 页面所有站内链接，点击后会被替换为HTTPS地址再跳转;

跟其它所有CSP 规则一样，这个指令也有两种方式来启用，具体格式请参考上一节。需要注意的是upgrade-insecure-requests只替换协议部分，所以只适用于HTTP/HTTPS 域名和路径完全一致的场景。

三、合理使用HSTS

在网站全站HTTPS 后，如果用户手动敲入网站的HTTP 地址，或者从其它地方点击了网站的HTTP链接，依赖于服务端301/302跳转才能使用HTTPS 服务。而第一次的HTTP 请求就有可能被劫持，导致请求无法到达服务器，从而构成 HTTPS 降级劫持。

HSTS 基本使用

这个问题可以通过 HSTS(HTTP Strict Transport Security，RFC6797)来解决。HSTS 是一个响应头，格式如下：

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age，单位是秒，用来告诉浏览器在指定时间内，这个网站必须通过HTTPS 协议来访问。也就是对于这个网站的HTTP 地址，浏览器需要先在本地替换为HTTPS 之后再发送请求。

includeSubDomains，可选参数，如果指定这个参数，表明这个网站所有子域名也必须通过HTTPS 协议来访问。

preload，可选参数，后面再介绍它的作用。

HSTS 这个响应头只能用于HTTPS 响应;网站必须使用默认的443 端口;必须使用域名，不能是IP。而且启用HSTS 之后，一旦网站证书错误，用户无法选择忽略。

HSTS Preload List

可以看到 HSTS 可以很好的解决HTTPS 降级攻击，但是对于HSTS 生效前的首次HTTP 请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了HSTS Preload List 方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用HTTPS 协议。

目前这个Preload List 由Google Chrome 维护，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加进这个列表，首先需要满足以下条件：

·拥有合法的证书(如果使用SHA-1 证书，过期时间必须早于2016 年);

·将所有 HTTP 流量重定向到HTTPS;

·确保所有子域名都启用了HTTPS;

·输出HSTS 响应头：max-age 不能低于18 周(10886400 秒);必须指定includeSubdomains 参数;必须指定preload 参数;

即便满足了上述所有条件，也不一定能进入HSTS Preload List。通过Chrome 的 chrome://net-internals/#hsts 工具，可以查询某个网站是否在Preload List 之中，还可以手动把某个域名加到本机 Preload List。

对于HSTS 以及HSTS Preload List，我的建议是只要你不能确保永远提供HTTPS 服务，就不要启用。因为一旦HSTS 生效，你再想把网站重定向为HTTP，之前的老用户会被无限重定向，唯一的办法是换新域名。

四、CDN 安全

对于大站来说，全站迁移到HTTPS 后还是得用CDN，只是必须选择支持HTTPS 的CDN 了。如果使用第三方CDN，安全方面有一些需要考虑的地方。

五、合理使用SRI

HTTPS 可以防止数据在传输中被篡改，合法的证书也可以起到验证服务器身份的作用，但是如果 CDN 服务器被入侵，导致静态文件在服务器上被篡改，HTTPS也无能为力。

W3C 的SRI(Subresource Integrity)规范可以用来解决这个问题。SRI 通过在页面引用资源时指定资源的摘要签名，来实现让浏览器验证资源是否被篡改的目的。只要页面不被篡改，SRI 策略就是可靠的。

SRI 并不是HTTPS 专用，但如果主页面被劫持，攻击者可以轻松去掉资源摘要，从而失去浏览器的 SRI 校验机制。

六、了解Keyless SSL

另外一个问题是，在使用第三方CDN 的HTTPS 服务时，如果要使用自己的域名，需要把对应的证书私钥给第三方，这也是一件风险很高的事情。

Keyless SSL 技术让你可以不把证书私钥给第三方，改为提供一台实时计算的Key Server 即可。CDN 要用到私钥时，通过加密通道将必要的参数传给 Key Server，由 Key Server 算出结果并返回即可。整个过程中，私钥都保管在自己的 Key Server 之中，不会暴露给第三方。

好了，本文先就写到这里，需要注意的是本文提到的 CSP、HSTS 以及 SRI 等策略都只有最新的浏览器才支持，详细的支持度可以去CanIUse查。切换到HTTPS 之后，在性能优化上有很多新工作要做，这部分内容我在之前的博客中写过很多，这里不再重复，只说最重要的一点：既然都HTTPS了，赶紧上HTTP/2才是正道。

相关阅读：

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

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

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

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