全站 HTTPs,没那么简单

3,462 阅读9分钟
原文链接: mp.weixin.qq.com

“全站HTTPs”俨然成了目前的热门话题,很多网站都在摩拳擦掌要实行全站HTTPs。凑巧,我们(沪江)也在推行这个计划。

一开始大家想得都很简单,把证书购买了、配好了,相应的路径改一改,就没有问题。事实也确实如此,单个独立站点的HTTPs改造是很容易的。一旦走向“全站”,才发现事情远远比想象的要复杂,全站意味着所有资源面对所有客户端,涉及的因素异常多,网络上又没有太多资料,只能自己摸索。下面我简单讲讲遇到的几个问题,提供一些经验给大家参考。

HSTS

如果一个网站既提供了HTTP服务,又提供了HTTPs服务(在过渡期通常如此),怎样引导用户访问HTTPs的站点呢?这就是HSTS(HTTP Strict Transport Security)的作用。通过Web服务器上的设置,在收到HTTP访问请求时,返回的header里带有Strict-Transport-Security字段,告知浏览器必须使用HTTPs进行访问。

但是,HSTS并不能避免首次跳转时遇到的劫持。要彻底解决这个问题,可以申请加入Preload List(预加载列表)。

Preload List是由Google Chrome维护的“HTTPs站点列表”,Chrome, Firefox, Safari, Edge, IE 11均在使用。一旦浏览器发现要访问的站点在Preload List上,默认就会发起HTTPs链接。这样,就避免了HSTS的首次跳转被劫持的隐患。

SSL卸载

通常的方案里,HTTPs的加密传输只限于客户端出发的公网阶段,在内网的通讯流量仍然采用非加密的HTTP传输。这种“把加密流量转换为非加密流量”的过程,就是常说的SSL/TLS卸载(Offloading,以下简称“SSL卸载”)。

有一些公司会采用F5来做负载均衡,F5应付单纯的L4和L7的流量是没有问题的,但进行SSL卸载时性能往往会急剧降低,F5可以提供专门的加速卡来解决这个问题,但价格不便宜。所以,还需要专门环节来进行SSL卸载,常见的Nginx和HAProxy都可以执行这个任务。

2010年Intel出品的Westmere系列处理器之后,CPU支持AES-NI(Advanced Encryption Standard New Instructions)指令集,可以极大提高软件进行SSL加解密的速度(通常的数据是5倍左右)。但是,单纯采用CPU并不会直接享受这种好处,还需要对应的OpenSSL提供支持。想要知道自己的OpenSSL是否利用了AES-NI加速,可以用OpenSSL的命令行调试,加上-evp参数,测试速度是否有明显变化即可。

# without EVP API
openssl speed aes-256-cbc 
Doing aes-256 cbc for 3s on 16 size blocks: 14388425 aes-256 cbc's in 3.00s
# with EVP API
openssl speed -evp AES256
Doing aes-256-cbc for 3s on 16 size blocks: 71299827 aes-256-cbc's in 3.00s

客户端证书

HTTP的服务是很好验证的。一般来说,无论客户端是浏览器,还是其它工具,还是程序代码,同样的行为,结果都是相同的。所以只要一种客户端验证通过,基本就可以认为这个服务是没有问题的。HTTPs的站点则不是如此。

与HTTP不同,HTTPs的连接建立是需要进行证书验证的,一定要从根证书开始形成完整的信任链条,连接才可以建立成功。然而,浏览器、普通工具、程序类库,它们所信任的根证书在管理上是互相独立的。比如,与浏览器不同的是,C#信任的根证书在local machine store或者current user store中,Java信任的根证书在JDK安装目录下的cacerts目录中。

因为浏览器的证书在使用中又可以持续更新,用户往往感知不到,如果“想当然”认为浏览器验证通过就万事大吉,很可能会出问题。比如国内有不少网站使用WoSign签发的证书,但老版本的JDK并步信任WoSign的根证书,用浏览器浏览没问题的网站,程序就会报错,除非手动导入证书。因为WoSign行为不端,前几天Firefox, Chrome, Safari等主流浏览器又取消了对它的信任,也就意味着WoSign证书有安全风险,所以已经内置WoSign根证书的程序也应当做对应的设置。

服务器端证书

还是上面的现象:用浏览器验证没有问题的HTTPs站点,用程序访问就有问题。这是为什么?

在服务器上证书配置错误,只有最终证书,而缺少中级证书的情况,我见过几次了。通常,最终证书里包含了中级证书相关的信息,所以如果缺少中级证书,浏览器为了建立证书链,会做一次耗时的操作来获取中级证书,而且这一切都发生在HTTPs连接真正建立之前。更糟糕的是,不少浏览器为了“表现更好”,会想办法绕过这个问题。所以缺少中级证书的情况一直存在,一直不会被发现,而程序调用的速度总是上不去,甚至有一定几率报错(我就遇到过这个诡异的问题)。

如果把证书链配置完全,还要注意证书链的大小。有一些网站的完整证书异乎寻常地大,达到若干kb甚至几十kb,也就是说,在建立连接之前,就必须先传输这么多的数据。如果做单纯的PC网页浏览,或许不会有问题。但对于移动端和程序调用来说,这就是一场灾难。最好的办法,是用OpenSSL配合WireShark之类的工具,自己动手来测试。如果你熟悉TCP相关的知识,往往可以得到更好的优化方案。

OCSP和CRL也不可忽略。这两项技术用来保证撤回证书(让证书失效)的有效性。如果你仔细观察,会发现证书里都指定了对应的OCSP或者CRL的URL,用来检查证书是否失效。按道理说,在每次建立HTTPs连接时,都应当进行OCSP或CRL检查。返回结果通常在1k左右,如果请求非常频繁,这个因素也应当考虑。

SNI

大家都熟悉“虚拟主机”的概念,它可以让多个域名对应到同一个IP,让同一台服务器服务多个站点。在HTTP时代,可以在header中通过host来指定需要访问的域名,一切看起来都那么完美。

但是在HTTPs时代,却没有这样的好事,传统的HTTPs服务很难让多个域名对应到同一个IP。在进行到HTTP通讯之前,必须先建立验证证书建立连接。如果一个IP上绑定了多个域名,这个阶段服务器根本没法知道请求对应的是哪个域名,无疑会造成极大的不便。

为了解决这种问题,SNI(Server Name Identification)应运而生了。这种技术说起来复杂,大家可以把它简单理解为“建立SSL/TLS通讯时的host header”,这样就解决了一个IP只能配单张证书的问题。

然而SNI的诞生历史并不长,许多客户端的支持都存在奇怪的问题。比如JDK7支持SNI,但是JDK8的支持又有bug。而且这种支持往往需要调用原生的API才可以实现,Resteasy之类的类库并不支持。如果对SNI的支持有问题,即便配置正确也可能无法建立连接,因为服务端并不能识别此请求需要的证书。

CDN

CDN已经是业界流行的技术了,对稍微大一点的网站来说,没有CDN几乎是不可想象的。HTTP时代的CDN方案相当成熟,HTTPs的情况则不是如此。

要使用HTTPs的CDN服务,就要决定是否将证书交给CDN提供商。基于中国目前的商业信誉水平,把证书交给CDN提供商的风险不可步考虑。恶意揣测,别有用心的人一旦拿到证书,可以很方便地通过DNS劫持发起中间人攻击,而完全不被感知到。

另外,HTTP时代大家都喜欢将资源分散到多个不同的域名,因为建立连接的成本很低,而同一个域名的并发连接数有限。在HTTPs环境下,每次建立连接的成本高了很多,频繁下载和验证证书对移动设备和移动网络影响很大(尤其是证书很大的情况)。如果域名非常分散,影响就更加显著。所以在HTTPs时代,把域名收缩集中反而是更好的办法。

内容及其它

因为HTTPs的内容中无法引用HTTP的资源,所以应当保证网页中资源文件的链接都是HTTPs的。遗留的许多系统很可能并不注意这些事情,资源都采用绝对地址的形式,这样改起来工作量很大。如果要修改,最好一步到位,直接改成“协议相对URL”。

绝对地址URL:http://www.a.com/b.css

协议相对URL://www.a.com/b.css

这样浏览器就可以根据当前的协议,自动生成资源的绝对地址,无论是HTTP还是HTTPs,都可以自由切换。

如果资源都是自有的,切换HTTPs就相对容易。如果存在外部,尤其是UGC的资源,切换到HTTPs就很麻烦。如果是超链接,通常采用专门的跳转服务,也就是下面这样:

https://link.my.com/target=www.you.com

如果是图片这类资源,可以设定专门的程序将其抓取过来存放在自己的服务器上,再将地址替换掉即可。但是,这样做很可能要自己承担流量压力,同时还要承担恶意程序攻击的风险。

如果是视频、游戏等富文本、交互复杂的资源,如果源站没有提供HTTPs的服务,多半只能忍痛割爱,放弃内嵌展现的形式了。

最后再补充两点经验:

  1. 如果真的决定上HTTPs,最好有个人把OpenSSL玩熟,否则很多问题会让你摸不着头脑,OpenSSL是很好的调试工具,很方便定位问题。

  2. HTTPs能解决运营商内容劫持的问题,如果是DNS劫持,要不要抱着“吾与汝偕亡”的态度上HTTPs,需要慎重考虑,我知道不少网站是HTTP与HTTPs可以随时切换的,进可攻,退可守。