HTTPS真的就是安全的象征吗？HTTPS检查工具带来的安全威胁

在很多人印象中，HTTPS就是安全的象征，而为了对这些“安全”的流量进行检查，很多安全产品，包括杀毒软件和防火墙都具备HTTPS检查的功能，通过这样的功能排除其中的安全威胁。然而近日US-CERT却发布了一则预警，TA17-075A，对部分HTTPS检查产品发出安全预警，提到部分SSL/TLS拦截软件未能执行有效验证，或者未能充分传递验证状态，这可能被第三方发动中间人攻击。

US-CERT为什么要发出这个 预警呢？让我们来捋一捋最近发生的一些事情。

US-CERT专家发文称SSL检查有风险

首先是2015年初的时候， Superfish和 PrivDog这两款SSL检查工具因为没能正确验证SSL引起了US-CERT专家的重视。专家称因为没能正确验证SSL，导致用户系统容易被攻击者进行HTTPS嗅探。

接连几个SSL检查工具被曝存在相似问题后，US-CERT专家Will Dormann决定深入探究这个问题，发表了《SSL检查的风险》一文，其中指出了一些问题：

1. 许多人并不了解SSL和TSL的功能；

2. SSL检查产品比他想象的流行得多；

3. 许多有SSL检查能力的应用都存在一些漏洞，可给用户带来风险；

4. 即便SSL检查做得跟浏览器一样安全，也会给用户带来一定风险。

下面我们一一来讲。

背景知识

SSL和TLS的目的主要有两个：一是认证与客户端通信的服务器，二是加密客户端与服务器之间发送的数据。有些人可能认为SSL和TLS能够实现端到端加密，这种观点是不对的。SSL和TLS只有在点到点的情况下才能实现安全认证和加密。我们先来看个例子，在本例中的点到点通信也可以被认为是端到端的通信：

客户端能够验证安全通信，但只能和其通信的下一个点进行验证。在上面的例子当中，客户端直接和目标系统建立SSL/TLS连接。客户端软件通过系统上的大量根证书来验证它连接的系统。至于这个系统是不是用户预期的目标系统就是需要另作讨论的话题了。

当用户在浏览器当中加载受HTTPS保护的网站时，浏览器实际上只会验证两件事：网站是否提供了证书；证书是不是浏览器信任的根证书CA机构颁发的。实际上我们是在相信每个根CA机构都已尽全力来验证你要连接的服务器的身份。但是实际上有时候根CA机构会被骗。我们还相信每个根CA机构都能够保护自己的系统。但是实际上有时候根CA会被盗用。

有关这些问题的更多细节，请参阅Moxie Marlinspike的博客文章《 SSL与真实的未来》。

我们上面提到的Superfish和Privdog有什么问题呢？它们会安装一个新的受信根证书。

请注意这里使用术语“可信”。 我们不是在讨论PGP和GPG应用程序使用的信任网络的任何内容，在PGP中的“可信”是指使用个别密钥的信任级别。 而“受信任的根CA证书”只是可以由客户端软件使用而不产生警告。 它与用户对某事物的“信任”毫无关系。简单来说，有了这个证书，客户端软件就不会发出安全警告提示你证书有问题。

这两个工具都会安装受信的根CA证书，不过好消息是他们的证书都明确写明是来源于Superfish和Privdog。如果有软件要把证书冒充成是由“VeriSign”等大机构发布的，写成“VeriSign.”我们也无法防范。

假定有这样一个场景，有人通过HTTPS访问一家网站（因为要给出诸如用户名和密码这样的敏感信息），装了PrivDog或者Superfish。如果浏览器不对证书合法性作警告，最多也就意味着与用户通讯的系统，获得了受信root CA机构的证书，SuperFish和Privdog就是其中之一。

如果有人想要验证某个证书是否由“真正”的证书机构发布的，比如说想要查看证书发行机构的指纹，所需的步骤在每个浏览器当中也各有不同。有些浏览器，比如微软的IE，如果要查看证书还得先接受该证书，因此即便是安全专家可能也很难判断是不是他想要连接的主机。

Superfish和Privdog这种主机层面的软件仅仅是SSL检查产品的一部分。Dormann发现，许多网络层面的应用和设备也能进行SSL检查。安全网关、防火墙、数据丢失防护（DLP）产品和其他许多应用似乎都加入了SSL检查的大军。当然了，网络管理员要检查受SSL/TLS保护的浏览可能有多种多样的原因，但是很多人可能都没有注意到，那些软件的SSL检查能力还不如浏览器，会带来什么样的安全隐患不言而喻。我们来看看这个图：

在上图的通信过程中，客户端只能验证自己是在与SSL检查软件通信。客户端并不清楚SSL检查软件用了什么技术验证SSL证书。而且更重要的是，SSL检查软件跟目标系统之间还有没有额外的点，客户端无法确定。SSL检查软件跟目标服务器之间是否有攻击者存在？客户端无法知晓。由于这种不透明，客户端只能相信SSL检查软件每一步都做到位了。但很不幸，SSL检查软件并没有。

常见的SSL错误

分析了SSL检查软件之后，Dormann等人总结了这些软件经常犯的一些错误：

1. 上游证书有效性验证不充分

风险：客户端无法知晓所连站点是否合法正规

2. 未告知客户端上游证书验证结果

风险：客户端无法知晓所连站点是否合法正规

3. 证书规范名称字段信息过载

说明：有些SSL检查软件会通过证书的CN字段，试图将上游证书的有效性传递给客户端。比如说，Komodia的SSL Digestor如果验证服务器端提供的证书无效，就会在证书的CN字段开头加上“verify_fail”字样。这个技术其实会带来很多问题。最明显的错误就是传递给用户的错误信息跟证书无效的原因没有关系。

风险：客户端系统的用户可能不知道为什么证书验证没有通过，或者甚至不知道验证没通过。攻击者可以利用主题替代方案名称（SAN）字段令证书认证某一特定域，这样浏览器就不会发出警告。

4. 用应用层反馈证书有效性

说明：有些SSL检查工具会将网页内容（比如HTML）提供给客户端，并描述证书的问题。但客户端软件确定和展示证书的一般机制可能还是会提示证书没有问题。

风险：用HTTPS访问数据的并不一定是人。客户端可能是用JSON数据跟服务器通信的某个应用。这个问题还可能导致SSL有效性提示不一致。

5. 根据UA HTTP头决定何时验证证书

说明：有些软件会根据客户端提供的UA HTTP头选择性决定验证上游证书的时间。这个技术可能是和上面的步骤一起使用的。

风险：使用这种机制就会导致部分客户端都不能收到证书认证信息。

6. 预警之前建立通信

说明：有些SSL检查工具检测到证书错误后，会先把客户端请求发送到服务器，然后再给用户发警告信息。

风险：攻击者可能可以查看或修改敏感信息。

7. 使用相同根证书

说明：有些SSL检查应用每次安装的时候都使用相同的受信根证书。

风险：攻击者可能获得这些应用的私钥，并且用这个受信根证书来给所有访问网站签名。

Dormann认为，即便SSL检查应用不存在上述任何问题，客户端还是无法获知该应用信任了哪些根证书。使用SSL检查软件将阻碍或者完全阻止客户端成功验证其通信的服务器。

后来Dormann用自己信任的中间人代理虚拟机CERT Tapioca检测，发现有至少58个HTTPS检查工具都存在上述安全问题。

谷歌、Mozilla专家联合发布论文《HTTPS拦截的安全隐患》

基于上述的研究，来自密歇根大学、伊利诺伊大学厄本那-香槟分校、Mozilla、Cloudflare、Google、加州大学伯克利分校的研究人员决定对外界HTTPS拦截进行全面的研究，量化其流行程度和对现实世界安全的影响。

流量监控

研究人员首先对总体流量进行分析，通过三种渠道分别监控来自用户的流量，然后分辨用户是否使用了HTTPS流量监测工具。怎么进行分辨呢？比如有一些安全产品在拦截流量后会修改User-Agent，研究人员进行分析就可以分辨哪些流量经过拦截，哪些没有被拦截。他们发现Firefox更新连接有4.0%遭到拦截，6.2%的电商网站流量被拦截，10.9%的Cloudflare流量被拦截，这比之前估计的比例要高。

A. Firefox更新服务器

相比其他浏览器，Firefox流量被拦截的比例更低，原因就在于Firefox有自带的证书存储，而IE、Chrome、Safari浏览器都使用了系统默认的证书存储空间。因此，有些杀毒软件如Avast不会拦截Firefox的流量。在企业环境中，尽管可以额外在Firefox的证书管理中添加证书，但这还是会增加麻烦，因此很多IT管理员就索性不再拦截Firefox流量。

研究人员还观察到一些地理差异，比如危地马拉有15%的Firefox更新服务器流量被拦截，这比全球的平均比例要高3-4倍，原因是危地马拉的移动运营商COMCEL处理了34.6%的更新流量而运营商对32.9%的流量进行了拦截。格陵兰拦截率排在第二，主要是因为一个名为TELE Greenland的运营商的AS(自治系统)导致的，其中将近一般的流量都被Fortigate中间盒拦截。排名第三的韩国是使用手机最多的国家之一，大量的流量加上运营商AS系统中的拦截导致其拦截率较高。

B. 电商网站

研究人员观察了25万独立访客，并对HTTP User-Agent进行分析，识别出TLS握手时与UA浏览器不符的流量，结果观察到6.8%的流量被拦截，另外0.9%可能被拦截但无法完全分类。通过对指纹进行分析发现，电商网站被拦截的流量中58%被反病毒软件拦截，35%属于企业代理，只有1.0%来自恶意软件（如SuperFish）。拦截最多流量的三款杀毒软件分别是Avast、Blue Coat和AVG，分别拦截了10.8%，9.1%和7.6%的流量。

Chrome浏览器处理了40.3%的TLS流量，其中8.6%被拦截，是被拦截比例最高的浏览器。而手机端Safari的浏览器是最低的，仅拦截了0.9%。研究人员还观察到，Windows平台的流量拦截比例为8.3%–9.6%，而Mac平台则是2.1%，原因可能是大部分的企业用户使用的是Windows，并且很多杀毒软件是基于Windows的。

C. Cloudflare流量

通过检查Clouldflare拦截的流量，研究人员观察到10.9%的拦截率，握手环节中比例最高的指纹来自杀毒软件Avast, AVG, Kaspersky和BitDefender。这与在电商网站得出的结论相互印证。

对安全性的影响

接下来，为了评估HTTPS检查工具对安全的影响，研究人员制定了分级标准量化TLS客户端安全性：

A: 最优

被拦截后的TLS连接与浏览器本身的安全性和性能一致，在对密码套件区分等级时，研究人员使用了Chrome对“安全TLS”的定义。

B: 次优

连接使用了不理想的设置（比如非PFS密码）但是不至于被已知的攻击方法攻击

C: 连接可被已知攻击手法攻击

连接能被已知的TLS攻击手法（如BEAST，FREAK或Logjam）攻击，接受768位的Diffie-Hellman密钥或者支持RC4。

F: 严重缺陷

连接非常不安全，使用中间人攻击就可以截获并解密会话。比如产品不检验证书，或者提供不安全的密码套件（如DES）。

不过值得注意的是很多浏览器引入了新的安全校验机制如HSTS, HPKP, OneCRL/CRLSets, certificate transparency 验证和OCSP  must-staple。而测试的安全产品并不支持这些机制。从这个意义上说，即使获得了“A”等级，Chrome或者Firefox浏览器还是要比这些HTTPS检查工具更安全。

研究人员安装了各类HTTPS检查工具，包括企业代理、安全软件、以及包含HTTPS拦截功能的恶意软件，然后使用Chrome、IE、Firefox和Safari浏览器检查如下项目：

1) TLS版本

检查产品支持的最高版本TLS。客户端最高支持TLS 1.1时评级为B，支持SSLv3评级为C，支持SSLv2评级为F。

2) 密码套件

检查客户端问候消息中的密码套件。把所有不支持Chrome的强TLS密码的产品评级为B，握手时提供RC4的评级为C，支持其他更弱密码如出口级密码或者DES则评为F。

3) 证书验证

使用一些不能信任的证书，包括过期的，自签名的，或者签名无效的证书。并且测试了一些由公开了密钥的证书机构（如Superfish、eDell、Dell提供商的根证书）签署的证书。如果HTTPS检查工具接受了这些证书则评级为F。

4) 已知的TLS攻击

检查客户端能否被BEAST、FREAK、Heartbleed和Logjam攻击，检查是否接受不够安全的Diffie-Hellman密钥，符合上述条件则评级为C。

企业中间件

研究结果显示：

11/12款软件的默认设置降低了连接的安全性；

5/12款存在严重漏洞；

10/12款接受RC4加密方式；

2/12款使用了出口级的密码；

3/12款证书验证存在问题；

客户端安全软件

测试的软件几乎都存在问题，并且研究人员注意到，杀毒软件本身也存在漏洞，光Avast一款杀软过去8个月就有10个漏洞被公开，其中还有一个漏洞能能够被构造的证书执行远程代码。

恶意软件

之前研究人员发现Komodia没有验证证书，而新的发现显示NetFilter SDK也没有进行验证。因此这两款软件被评级为F。

对TLS流量的影响

研究人员观察到，65%截获的Firefox更新流量降低了安全性，37%存在严重漏洞。而27%的电商流量和45%的Cloudflare流量降低了安全性，能被黑客实现中间人攻击的比例分别为18%和16%。

企业中间件

企业中间件拦截流量后62.3%的连接安全性降低了，而58.1%的连接存在严重漏洞。

在检查Firefox流量时，研究人员调查了处理100K个连接的AS系统中拦截率最高、设备指纹出现次数最多的前25个。其中发现的机构包括金融公司、政府部门和教育机构。除了一家银行以外，前25个AS中24个都降低了安全性。12个使用了出口级的密码套件，可能被中间人攻击。

存在问题的安全产品和厂商如下图：

在论文结尾，研究人员针对目前HTTPS拦截的现状提出了几点意见：

安全社区需要达成共识

我们需要社区共识。安全社区对是否应该允许HTTPS拦截几乎没有共识。一方面，Chrome和Firefox通过允许本地安装根证书绕过限制。而与此同时，采用新的协议特征来进行更安全的拦截的讨论又在IETF这样的标准化小组里遭到了大量反对。

想要找到长久有效的解决方案，安全社区必须要在“拦截检查是否合理”这一问题上达成共识。

应该考虑验证发生的环节

许多HTTPS安全功能希望通过混合HTTP和TLS层来实现端到端的连接，并通过在浏览器代码中实现HTTPS功能，而不是在TLS库中。例如，为了克服现有吊销证书协议的弱点，Firefox有OneCRL机制，而Chrome有CRLSets。这两种解决方案都能在典型的端到端情况下增加浏览器的安全性。然而，这些解决方案在TLS代理的存在下不提供任何保护，并且由于该解决方案不是TLS协议本身的一部分，所以TLS库不实现这些安全检查。比如，HPKP指令通过HTTP传递，而不是在TLS握手期间传递。浏览器无法对代理连接执行HPKP验证，因为它们无法访问目标证书，而代理又不会不执行验证。虽然代理有能力执行额外的验证，但却没有验证。而且在许多情况下，厂商的精力都花费在正确部署现有TLS库上，更不用说实现其他安全功能了。

如果我们希望浏览器执行额外的验证，那么代理就需要一种将连接详细信息（即服务器证书和加密参数）传递给浏览器的机制。如果要代理执行此验证，我们需要在TLS中标准化这些验证步骤，并使用流行的库。但是现在的情况是最糟糕的——任何一方都不执行严格的验证机制。

加密库需要提供安全的默认值

几个代理部署了经过很少修改定制的TLS库。但这些库的默认设置是有安全问题的。默认情况下，客户端库和Web服务器应该优先考虑使其产品安全。OpenSSL最近决定删除已知的密码密码套件，这样的行为就值得赞赏。OpenSSL十年前就应该这么做了。我们的社区应该继续将默认选项限制为已经被证明安全的配置。

防毒软件供应商应该重新考虑拦截HTTPS

防病毒软件在本地运行，可以访问本地文件系统，浏览器内存以及通过HTTPS加载的任何内容。由于他们可能会将TLS错误配置和RCE漏洞，我们强烈建议防病毒提供商重新考虑是否拦截HTTPS。

安全公司忽略了安全问题

我们希望通过披露现有产品的漏洞，我们可以鼓励厂商修补问题。希望企业优先考虑其TLS实施的安全性，并考虑HTTPS生态系统发展的步伐以及是否能够跟上必要的更新。

不要依赖客户端配置

客户端和服务器端都需要选择安全参数，而不是依靠一方来维持安全性。

管理员需要测试中间盒

鼓励部署代理的管理员使用诸如Qualys SSL Lab的客户端测试 https://howsmyssl.com和 https://badssl.com等网站来测试其配置。

安全厂商应该更负责

正是在Google研究人员发布报告后，美国计算机应急响应小组(US-CERT)加入了声浪。

US-CERT称，“HTTPS检查会削弱TLS的安全性，”而且告诉企业，如果他们需要对HTTPS进行审查，他们应该保证产品会“执行正确的TLS证书验证”。

 “由于HTTPS审查会管理协议、密钥、证书，因此产品应该要执行必要的HTTPS验证。”US-CERT的警告中称。

不过也有安全专家表达了不同的看法，安全专家David Holmes在SecurityWeek发表文章，指责发布论文的研究人员。他认为拦截HTTPS的首要目标是防范恶意软件。的确，很多企业会用到HTTPS拦截检查，因为无论是现在还是将来，他们的首要威胁都是恶意软件。很多恶意软件已经开始使用HTTPS来规避检测，因此要检查恶意软件别无他法。

笔者认为，安全厂商添加HTTPS检查功能的初衷是为了进行安全检查，想要像检查HTTP网页一样对内容进行检测，防止通信过程中的安全风险。现如今使用HTTPS的网站越来越多，浏览器厂商也在呼吁网站使用HTTPS协议，相关的证书的成本也在降低。

另一方面，HTTPS中的恶意流量也逐渐增多，甚至一些钓鱼网站也使用了HTTPS协议。而黑客窃取HTTPS证书自行签署网站证书，或者入侵HTTPS网站也是没有可能。从这个意义上说，针对HTTPS内容的检查十分必要。

2015年11月黑客窃取了世界银行的SSL证书搭建针对PayPal的钓鱼网站

但现实中，HTTPS检查却引入了新的安全问题，厂商对证书验证的疏忽、使用了存在问题的库都是产生问题的原因。整个事件带给我们的启示是，即便是安全厂商出品的安全产品也有可能存在安全问题，厂商在上线产品时应该进行严格的测试。

参考来源

The Risks of SSL Inspection

HTTPS Interception Weakens TLS Security | US-CERT

US Gov backs Google’s alarm: warns against HTTPS interception products – CSO | The Resource for Data Security Executives

CERT Tapioca | Vulnerability Analysis | The CERT Division – CERT. org

US-CERT’s Warning on SSL Interception vs. Security is a False Dichotomy | SecurityWeek.Com

The Security Impact of HTTPS Interception

*本文作者：kuma & Sphinx，转载请注明来自FreeBuf.COM