关于启用 HTTPS 的一些经验分享

随着国内网络环境的持续恶化,各种篡改和劫持层出不穷,越来越多的网站选择了全站 HTTPS。就在今天,免费提供证书服务的 Let's Encrypt 项目也正式开放,HTTPS 很快就会成为 WEB 必选项。HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能,可以有效防止数据被查看或篡改,以及防止中间人冒充。本文分享一些启用 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-blockableBlockable 两类:

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 的更多说明请看我之前写的《Subresource Integrity 介绍》。SRI 并不是 HTTPS 专用,但如果主页面被劫持,攻击者可以轻松去掉资源摘要,从而失去浏览器的 SRI 校验机制。

了解 Keyless SSL

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

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

CloudFlare 的这套机制已经开源,如需了解详情,可以查看他们官方博客的这篇文章:Keyless SSL: The Nitty Gritty Technical Details。

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

 

SSL 版本选择

TLS(Transport Layer Security,传输层安全)的前身是 SSL(Secure Sockets Layer,安全套接字层),它最初的几个版本(SSL 1.0、SSL 2.0、SSL 3.0)由网景公司开发,从 3.1 开始被 IETF 标准化并改名,发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。TLS 1.3 改动会比较大,目前还在草案阶段。

SSL 1.0 从未公开过,而 SSL 2.0 和 SSL 3.0 都存在安全问题,不推荐使用。Nginx 从 1.9.1 开始默认只支持 TLS 的三个版本,以下是 Nginx 官方文档中对 ssl_protocols 配置的说明:

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Context: http, server
Enables the specified protocols. The TLSv1.1 and TLSv1.2 parameters work only when the OpenSSL library of version 1.0.1 or higher is used.

但不幸的是,IE 6 默认只支持 SSLv2 和 SSLv3(来源),也就是说 HTTPS 网站要支持 IE 6,就必须启用 SSLv3。仅这一项就会导致 SSL Labs 给出的评分降为 C。

加密套件选择

加密套件(CipherSuite),是在 SSL 握手中需要协商的很重要的一个参数。客户端会在 Client Hello 中带上它所支持的 CipherSuite 列表,服务端会从中选定一个并通过 Server Hello 返回。如果客户端支持的 CipherSuite 列表与服务端配置的 CipherSuite 列表没有交集,会导致无法完成协商,握手失败。

CipherSuite 包含多种技术,例如认证算法(Authentication)、加密算法(Encryption)、消息认证码算法(Message Authentication Code,简称为 MAC)、密钥交换算法(Key Exchange)和密钥衍生算法(Key Derivation Function)。

SSL 的 CipherSuite 协商机制具有良好的扩展性,每个 CipherSuite 都需要在 IANA 注册,并被分配两个字节的标志。全部 CipherSuite 可以在 IANA 的 TLS Cipher Suite Registry 页面查看。

OpenSSL 库支持的全部 CipherSuite 可以通过以下命令查看:

BASHopenssl ciphers -V | column -t
0xCC,0x14  -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH        Au=ECDSA   Enc=ChaCha20-Poly1305  Mac=AEAD
... ...

0xCC,0x14 是 CipherSuite 的编号,在 SSL 握手中会用到。ECDHE-ECDSA-CHACHA20-POLY1305 是它的名称,之后几部分分别表示:用于 TLSv1.2,使用 ECDH 做密钥交换,使用 ECDSA 做认证,使用 ChaCha20-Poly1305 做对称加密,由于 ChaCha20-Poly1305 是一种 AEAD 模式,不需要 MAC 算法,所以 MAC 列显示为 AEAD。

要了解 CipherSuite 的更多内容,可以阅读这篇长文《TLS 协议分析 与 现代加密通信协议设计》。总之,在配置 CipherSuite 时,请务必参考权威文档,如:Mozilla 的推荐配置、CloudFlare 使用的配置。

以上 Mozilla 文档中的「Old backward compatibility」配置,以及 CloudFlare 的配置,都可以很好的兼容老旧浏览器,包括 Windows XP / IE6。

之前见到某个大厂家居然支持包含 EXPORT 的 CipherSuite,这些套件在上世纪由于美国出口限制而被弱化过,已被攻破,实在没有理由再使用。

SNI 扩展

我们知道,在 Nginx 中可以通过指定不同的 server_name 来配置多个站点。HTTP/1.1 协议请求头中的 Host 字段可以标识出当前请求属于哪个站点。但是对于 HTTPS 网站来说,要想发送 HTTP 数据,必须等待 SSL 握手完成,而在握手阶段服务端就必须提供网站证书。对于在同一个 IP 部署不同 HTTPS 站点,并且还使用了不同证书的情况下,服务端怎么知道该发送哪个证书?

Server Name Indication,简称为 SNI,是 TLS 的一个扩展,为解决这个问题应运而生。有了 SNI,服务端可以通过 Client Hello 中的 SNI 扩展拿到用户要访问网站的 Server Name,进而发送与之匹配的证书,顺利完成 SSL 握手。

Nginx 在很早之前就支持了 SNI,可以通过 nginx -V 来验证。以下是我的验证结果:

BASH./nginx -V
nginx version: nginx/1.9.9
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
built with OpenSSL 1.0.2e-dev xx ? xxxx
TLS SNI support enabled
configure arguments: --with-openssl=../openssl --with-http_ssl_module --with-http_v2_module

然而,并不是所有浏览器都支持 SNI,以下是常见浏览器支持 SNI 的最低版本:

浏览器最低版本
ChromeVista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox2.0+
Internet Explorer7+ (需要 Vista+)
Safari3+ (需要 OS X 10.5.6+)
Mobile SafariiOS 4.0+
Android Webview3.0+

可以看到,现在还有一定用户量的 Windows XP IE6~8、Android 2.x Webview 都不支持 SNI。如果要避免在这些浏览器中出现证书错误,只能将使用不同证书的 HTTPS 站点部署在不同 IP 上,最简单的做法是分开部署到不同机器上。

另外,包含 SAN(Subject Alternative Name)的证书能同时支持多个域名,也可以用于解决这个问题。

证书选择

HTTPS 网站需要通过 CA 取得合法证书,证书通过数字签名技术确保第三方无法伪造。证书的简单原理如下:

  • 根据版本号、序列号、签名算法标识、发行者名称、有效期、证书主体名、证书主体公钥信息、发行商唯一标识、主体唯一标识、扩展生成 TBSCertificate(To Be Signed Certificate, 待签名证书)信息;
  • 签发数字签名:使用 HASH 函数对 TBSCertificate 计算得到消息摘要,用 CA 的私钥对消息摘要进行加密,得到签名;
  • 校验数字签名:使用相同的 HASH 函数对 TBSCertificate 计算得到消息摘要,与使用 CA 公钥解密签名得到内容相比较;

使用 SHA-1 做为 HASH 函数的证书被称之为 SHA-1 证书,由于目前已经找到 SHA-1 的碰撞条件,将证书换成使用更安全的 SHA-2 做为 HASH 函数的 SHA-2 证书被提上日程。

实际上,微软已经宣称自 2017 年 1 月 1 日起,将全面停止对 SHA-1 证书的支持。届时在最新版本的 Windows 系统中,SHA-1 证书将不被信任。

而根据 Chrome 官方博客的文章,使用 SHA-1 证书且证书有效期在 2016 年 1 月 1 号至 2016 年 12 月 31 号之间的站点会被给予「安全的,但存在漏洞」的提示,也就是地址栏的小锁不再是绿色的,并且会有一个黄色小三角。而使用 SHA-1 证书且证书有效期超过 2017 年 1 月 1 号的站点会被给予「不安全」的红色警告,小锁上直接显示一个红色的叉。

然而,并不是所有的终端都支持 SHA-2 证书,服务端不支持还好办,浏览器只能依赖于用户升级了。下面是常见浏览器支持 SHA-2 证书的最低版本:

浏览器支持 SHA-2 证书的最低版本
Chrome26+
Firefox1.5+
Internet Explorer6+ (需要 XP SP3+)
Safari3+ (需要 OS X 10.5+)
Android Webview2.3+

可以看到,如果要照顾没有打 XP SP3 补丁的 IE6 用户,只能继续使用 SHA-1 证书。

在我之前的文章中,还提到过 ECC 证书,这种新型的证书支持度更差,这里略过不提,有兴趣的同学可以点这里查看。

是否可以针对不同浏览器启用不同证书呢?理论上服务端可以根据客户端 Client Hello 中的 Cipher Suites 特征以及是否支持 SNI 的特征来分配不同证书。现在有一些网站利用 IE on Windows XP 不支持 SNI 这个特性,配置使用 SHA-1 证书的 Default Server 给它们用。

本文先写这么多,很多策略都需要根据自己网站的用户来决定,例如我的博客基本没有 IE8- 用户,理所当然可以禁用 SSLv3。如果你的产品还有很多使用老旧浏览器的用户,那就必须为这些用户做兼容方案了。一种方案是:只把主域安全级别配低,将 XP 上 IE 用户的 HTTPS 请求直接重定向到 HTTP 版本,这样其它域名可以使用高安全级别的配置,运维起来比较方便。

资源替换

HTTPS 网页中加载的 HTTP 资源被称之为 Mixed Content(混合内容),我在之前的文章中详细介绍了 Optionally-blockableBlockable 两类 Mixed Content,也介绍了各种浏览器对 Mixed Content 的加载策略。为了最好的用户体验,HTTPS 网站不要出现任何 Mixed Content。换句话说,HTTPS 页面中所有资源都必须替换为 HTTPS 的。

代码层的替换比较简单,但一些存在数据库中的文本(例如商品描述中的图片地址)就很容易遗漏,需要特别注意。

如果你的网站只打算支持 HTTPS,将所有外链资源(CSS、JS、图片、音频、字体文件、异步接口等等)直接替换为 HTTPS 地址,再把网站 HTTP 请求重定向到 HTTPS 即可。

当前很多支持 HTTPS 的网站出于各种原因,针对老旧浏览器或特殊网络还是允许通过 HTTP 访问。这时候,强烈建议让所有资源服务都同时支持 HTTP/HTTPS 访问。这样只要页面在使用这些资源时省略协议部分,浏览器就能根据主页面协议类型来自动选择 HTTP/HTTPS 资源。例如:

HTML<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 传给第三方。

另外,本文同时出现了 ReferrerReferer 两种写法,如果对此有困惑,推荐阅读《Referrer 还是 Referer?》。

连通性

很多网站在启用 HTTPS 之后,都会接到无法访问的用户反馈。除去自身配置问题(我在《从启用 HTTP/2 导致网站无法访问说起》一文中列举了常见的配置错误)之外,很有可能是 HTTPS 连通性受到了干扰。

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

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

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

除特别注明外,本站所有文章均为duzhi原创,转载请注明出处来自https://www.duzhi.me/article/3392.html

联系我们

******

在线咨询:点击这里给我发消息

邮件:ashang.peng#aliyun.com

QR code