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 设计之初是一种端到端的协议,而 CDN 却是以中间人的方式工作。原始网站是如何授权给中间的 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 安全信任的基本原则,即私钥必须是严格保密、不能与第三方共享的。尽管也有替代的方案不要求用户共享私钥,比如使用客户证书或者共享证书方案,但是秘钥管理复杂,客户网站无法自主的撤销自己对 CDN 厂商的授权,作为可信第三方的 CA 也没有撤销体现授权关系的共享证书。
具体细节可以参考我们的论文原文和 Oakland 会上所作报告的演讲。
2. 实际攻击的案例
在现实互联网中,中国教育和科研网应急响应组 CCERT 在2014年初曾经收到过类似的攻击报告,苹果公司使用的 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 互联的网络环境中加密流量的授权问题,还没有形成最终的解决方案。因为最初的互联网设计原则之一是端到端,而今天许多中间盒子使得互联网到处都是中间人,类似 HTTPS 在 CDN 中的问题将普遍存在,许多问题值得我们进一步研究,也欢迎有兴趣的研究者、CDN 厂商的技术人员和我们合作研究。
作者简介
段海新,清华大学网络科学与网络空间研究院研究员,网络与信息安全实验室(NISL)主任,CCERT 应急响应组负责人,加州大学 Berkeley 访问学者,蓝莲花战队 联合创始人。长期从事网络安全相关的教学和研究,重点关注 DNS、CDN、PKI、Web、TLS 等基础设施和基础协议的安全,研究成果发表在 Oakland、USENIX Security、NDSS、SIGCOMM 的学术会议,在工业界引起广泛关注。
段海新主页:http://netsec.ccert.edu.cn/duanhx, 新浪微博:http://weibo.com/duanhx 。
- 文剑一飞 [Chrome 47.0|Windows 7] 2016-01-04 18:09 3 赞 回复
- 互联网管理感觉是:大家都不知道大家用的是什么,但是大家都用了我也用吧。
- POCMON [Firefox 43.0|Ubuntu] 2016-01-04 16:37 4 赞 回复
- 就像加密与反加密一样,必须同时存在,才能有发展