NSA 如何窃听 Google 的加密流量——当 HTTPS 遇到 CDN

华盛顿邮报曾根据斯诺登泄露出来的 PPT 报道过美国国家安全局（NSA）在云端监听 Google（包括 Gmail）和 Yahoo 用户的加密通信。然而我们知道 Gmail 是使用 TLS 保护的，NSA 是如何破解 Google 的 TLS 加密通信的呢？

图1. 在美国 NSA 和英国 GCHQ 联合计划 MUSCULAR 中，NSA 和 GCHQ 绕过 TLS 加密，在云端监听后端的明文通信 

1. 问题分析与测试

目前主流网站都依赖 HTTPS（HTTP over TLS/SSL）实现服务器认证、数据加密和完整性保护，比如 Google 几乎所有应用都在 HTTPS 的保护之下。同时，主流网站也普遍使用了 CDN（Content Delivery Network）技术（虽然有些互联网公司使用自己开发的类似平台，他们并不叫 CDN 这个名字），用以提高网站的性能、可靠性和安全性。目前，HTTPS 和 CDN 技术几乎都已成为商业网站必须的基础服务。

然而长期以来，HTTPS 和 CDN 两种技术的设计和发展是独立的，HTTPS 设计之初是一种端到端（End-to-End）的协议，而 CDN 却是以中间人（Man in the Middle）的方式工作。原始网站是如何授权给中间的 CDN 厂商、如何完成浏览器 – CDN – 原始网站之间的身份认证、秘钥交换和数据保护，以及如何撤销这种授权，无论学术界还是工业在以前都没有没有系统性的考虑。

我们在 Oakland’14（IEEE Symposim on Security & Privacy）发表了论文 “When HTTPS Meets CDN:  A Case of  Authentication in Delegated Service”，首次提出了 HTTPS 在 CDN 环境中授权服务的认证问题，把两种技术结合在一起进行了系统性的研究。我们调研了 Akamai、CloudFlare 等世界上主流的20个 CDN 服务商，以及一万多个支持 HTTPS 的热门网站（同时也是上述20个 CDN 厂商的客户），揭示出了当前 HTTPS 在 CDN 部署中的许多问题。

首先是 CDN 节点和后台源服务器之间的通信很容易受到中间人攻击。

我们测试了5个 CDN 厂商的后台通信，发现尽管浏览器到 CDN 节点的通信使用 HTTPS 加密，有的厂商使用明文的 HTTP 与后台服务器进行通信（CDN77、CDN.NET）；有的厂商虽然使用了 HTTPS，却不验证证书的有效性（即可以使用自签名的证书伪造任何网站，存在问题的厂商包括 CloudFlare 和 InCapsula）；有的厂商（如 Amazon 公司的 CloudFront)虽然要求合法证书，但是却不验证证书的 Common Name。

图2.有些 CDN 的后端通信使用不加密的 HTTP 进行传输

其次是浏览器和 CDN 节点之间的授权认证问题。

我们发现很多 CDN 厂商要求源网站提交自己的公钥证书和私钥，这严重破坏了 PKI 安全信任的基本原则，即私钥必须是严格保密、不能与第三方共享的。尽管也有替代的方案不要求用户共享私钥，比如使用客户证书（Custom Certificate）或者共享证书（Shared Certificate）方案，但是秘钥管理复杂，客户网站无法自主的撤销自己对 CDN 厂商的授权，作为可信第三方的 CA 也没有撤销体现授权关系的共享证书。

具体细节可以参考我们的论文原文和 Oakland 会上所作报告的演讲。

2. 实际攻击的案例

在现实互联网中，中国教育和科研网应急响应组 CCERT 在2014年初曾经收到过类似的攻击报告，苹果公司（Apple）使用的 CDN 厂商 Akamai 的某些节点已经受到了类似的攻击，导致苹果公司源网站上的 JavaScript 页面被替换成了翻墙软件自由门的使用手册。我们与 Akamai 的技术人员确认过，的确是他们的 CDN 节点和后台的服务器之间使用 HTTP 协议传输，导致通信被劫持，某些 CDN 节点的缓存数据被污染了。

本文一开始的问题，也是由于 HTTPS 在 CDN 实现中的问题所致。根据斯诺登泄露出来的PPT，我们知道美国国家安全局 NSA 和英国的情报机构 GCHQ 在他们联合计划 MUSCULAR 中，他们也使用了类似的技术监听 Yahoo 和 Google 的通信：由于类似 CDN 的 GFE（Google Front Engine）与提供内容的后台服务器使用了不加密或安全性较弱的通信协议，NSA 和 GCHQ 可以绕过浏览器端和 CDN 之间的 TLS，在后台直接监听明文的通信。正如图灵奖得主、著名密码专家 A. Shamir 所言：“Cryptography is typically bypassed, not penetrated.”

 3. 解决方案

在论文的撰写过程中，我们向涉及到的 CDN 厂商都通报了这一问题，并和 CloudFlare、Akamai 等公司的技术人员有过多次交流，我们所报告的问题得到了所有联系到的厂商的认可。其中，CloudFlare 公司在得到我们论文后，很快推出了更加安全的服务 Strict SSL，并宣称这一服务可以挫败 NSA 对后台通信的监听。

然而浏览器和 CDN 前端的授权问题却不只是实现上的问题。为解决这一 HTTPS 在 CDN 服务中的授权问题，我们在论文中提出并实现了一个基于 DANE的轻量级的解决方案，DANE (DNS-based Authentication of Named Entities）是 IETF 制定的标准，以完善 Web 网站的 PKI 信任模型。我们的实现表明，在 CDN 环境下实现安全、高效的 HTTPS 通信是可行的，但是由于 DNSSec 和 DANE 的部署并不普及，这一方案离工业界的普遍部署还有一定的距离。我们希望推进 CDN 和安全领域中进一步的研究，希望有更加有效的解决方案。

本文的第一作者梁锦津博士还参与了 CloudFlare 公司后来的一种解决方案——Keyless SSL的开发和测试工作。这一方案不要求客户网站与 CDN 共享私钥，而是在 CDN 在与前端浏览器进行 TLS 的认证和秘钥协商过程中，通过安全的信道把协商过程中的信息转发给源网站，由源网站提取会话秘钥或完成签名以后再提交给 CDN 节点。由于 TLS 的通信过程中只有握手过程中才用到私钥，以后的通信过程与源网站无关。清华大学计算机系张道维的本科毕业设计完成了 Keyless SSL 的的部分实现，实现中修改了 OpenSSL 和 Ngnix 的部分源代码，比较复杂，还有很大改进的空间。

受本论文的影响，互联网标准组织 IETF 的 CDN 互联工作组（CDNI）开始讨论 CDN 及 CDNI 互联的网络环境中加密流量的授权问题，还没有形成最终的解决方案。因为最初的互联网设计原则之一是端到端，而今天许多中间盒子（Middle Box）使得互联网到处都是中间人，类似 HTTPS 在 CDN 中的问题将普遍存在，许多问题值得我们进一步研究，也欢迎有兴趣的研究者、CDN 厂商的技术人员和我们合作研究。

作者简介

段海新，清华大学网络科学与网络空间研究院研究员，网络与信息安全实验室（NISL）主任，CCERT 应急响应组负责人，加州大学 Berkeley 访问学者，蓝莲花战队（Blue-Lotus） 联合创始人。长期从事网络安全相关的教学和研究，重点关注 DNS、CDN、PKI、Web、TLS 等基础设施和基础协议的安全，研究成果发表在 Oakland、USENIX Security、NDSS、SIGCOMM 的学术会议，在工业界引起广泛关注。

段海新主页：http://netsec.ccert.edu.cn/duanhx, 新浪微博：http://weibo.com/duanhx 。