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

  • A+
所属分类:业界资讯

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

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

图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”[2],首次提出了HTTPS在CDN环境中授权服务的认证问题,把两种技术结合在一起进行了系统性的研究。我们调研了Akamai、CloudFlare等世界上主流的20个CDN服务商,以及一万多个支持HTTPS的热门网站(同时也是上述20个CDN厂商的客户),揭示出了当前HTTPS在CDN部署中的许多问题。

首先是CDN节点和后台源服务器之间的通信很容易受到中间人攻击(图2):我们测试了5个CDN厂商的后台通信,发现尽管浏览器到CDN节点的通信使用HTTPS加密,有的厂商使用明文的HTTP与后台服务器进行通信(CDN77、CDN.NET);有的厂商虽然使用了HTTPS,却不验证证书的有效性(即可以使用自签名的证书伪造任何网站,存在问题的厂商包括CloudFlare和InCapsula);有的厂商(如Amazon公司的CloudFront)虽然要求合法证书,但是却不验证证书的Common Name。

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

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

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

具体细节可以参考我们的论文原文和Oakland会上所作报告的Slides[2]。

2. 实际攻击的案例

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

本文一开始的问题,也是由于HTTPS在CDN实现中的问题所致。根据斯诺登泄露出来的PPT(图1),我们知道美国国家安全局(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[4],并宣称这一服务可以挫败NSA对后台通信的监听。

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

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

受本论文的影响,互联网标准组织IETF的CDN互联工作组(CDNI)开始讨论CDN及CDNI互联的网络环境中加密流量的授权问题[6],还没有形成最终的解决方案。因为最初的互联网设计原则之一是端到端,而今天许多中间盒子(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

本文首发于“网络安全研究国际学术论坛(InForSec)” ,欢迎转发,但请注明出处:http://inforsec.org

参考文献:

[1] NSA infiltrates links to Yahoo, Google data centers worldwide, Snowden documents say. https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html

[2] Jinjin Liang, Jian Jiang, Haixin Duan, Kang Li, Tao Wan, and Jianping Wu. “When HTTPS Meets CDN: A Case of Authentication in Delegated Service”, in 2014 IEEE Symposium on Security and Privacy (SP), 2014, pp. 67-82, PDF and PPT Download: http://netsec.ccert.edu.cn/duanhx/archives/1803

[3]P. Hoffman and J. Schlyter. The DNS-Based Authentication of Named Entities (DANE),Transport Layer Security (TLS) Protocol: TLSA, RFC 6698 https://tools.ietf.org/html/rfc6698

[4] Nick Sullivan. Introducing Strict SSL: Protecting Against a Man-in-the-Middle Attack on Origin Traffic, https://blog.cloudflare.com/introducing-strict-ssl-protecting-against-a-man-in-the-middle-attack-on-origin-traffic/

[5]Keyless SSL, https://www.cloudflare.com/keyless-ssl/

[6]S. Slovetskiy ,Approaches to HTTPS-based Request Routing and Delegation, https://datatracker.ietf.org/doc/draft-slovetskiy-cdni-https-delegation-approaches/

SS推荐
老D

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:1   其中:访客  1   博主  0

    • avatar 依云 4

      如果是自己的资源,上 Subresource Integrity 就好了(不过微软又落后了:http://caniuse.com/#feat=subresource-integrity)。至于第三方的资源,只能依靠第三方的安全性了。