北京服务热线:18311033020 上海服务热线:13918452511 临沂服务热线:15376063995
新闻中心 在线申请 联系我们 手机版
公司新闻行业新闻电子商务建站经验网站建设网络营销其他新闻软文营销

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

文章来源:速点网络     发布时间:2016-01-07     阅读数:

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

 

1

 

图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。

 

2

 

其次是浏览器和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的部署并不普及,这一方案离工业界的普遍部署还有一定的距离。我们希望推进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)联合创始人。

责任编辑:文龙


上一篇:极简的设计,在用户体验上被高估了
下一篇:快播涉嫌传播淫秽案结束两日庭审 将改日宣判
最新案例
公司新闻
  1. 深圳市号令天下跑路 数百代理商投诉无门
  2. 临沂速点网络公司 您最佳的选择!
  3. 临沂速点网络技术有限公司放假通知
  4. 临沂最好的网络公司是哪家?独家分享临沂速
  5. 临沂速点网络方面的一站式服务
  6. 临沂网络推广公司哪家好?万名客户推荐临沂
  7. 临沂速点致力打造山东互联网公司第一品牌
  8. 企业网络营销首选临沂速点
最新资讯
  1. 网站优化中关键词的那些事儿
  2. 从收录到排名、从排名到流量需要经历什么?
  3. 百度不收录原因分析——spider抓取篇
  4. 招商加盟网站SEO优化怎么写好内容这一关
  5. 125个提升网页可用性的优化小技巧
  6. 5G不是梦!中移动计划2020年实现5G商用
  7. 云计算十年到底给我们带来了哪些变化?
  8. 打破国外垄断:中国高功率光纤激光器大突破
  • 【速点网络】北京销售部
    北京市通州区万达广场C座716室
    电话:18311033020
    客服QQ:2200093
  • 【速点网络】上海销售部
    上海浦东外高桥自贸区基隆路1号汤臣大厦713室
    电话:13918452511
    客服QQ:2200093
  • 【速点网络】临沂技术部
    临沂市罗庄区清河金街29号
    电话:15376063995
    客服QQ:2200093