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

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

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

《纽约时报》根据斯诺登泄露的PPT(图1)报道,美国国家安全局(NSA)在云端监控谷歌(包括Gmail)和雅虎客户之间的加密通信[1]。众所周知,Gmail是受TLS保护的。NSA是如何破解谷歌的TLS加密通信的?

图一。在美国NSA和GCHQ的协作方案Musical中,NSA和GCHQ绕过TLS加密,在云端监控后端密文通信。

1。问题分析和检测

目前流行的网站都是依靠HTTPS(HTTPoverTLS/SSL)来完成网络服务器验证、数据信息加密和一致性保护。例如,谷歌基本上使用HTTPS来保护所有网站。另外,CDN(ContentDeliveryNetwork)技术被广泛应用于热门网站(虽然有些互联网公司使用自己开发的类似服务平台,但不叫CDN),用于提升网站的特色、可信度和安全系数。现阶段,HTTPS和CDN技术已经基本成为商业服务网站必不可少的基础服务。

众所周知,HTTPS和CDN的设计方案和发展趋势一直是独立的。HTTPS设计方案一开始是一个端到端的协议,而CDN则是采用中间人的方法。初始网站如何授权给中间的CDN厂商,如何在电脑浏览器-CDN-初始网站中间进行认证、密钥交换和数据信息保护,以及如何撤销这种授权,无论学术界还是工业生产之前都没有给出任何针对性的考虑。

我们在Oakland'14(IEEEsymposiumonSecurity&Privacy)发表了毕业论文《当HTTPS遇上CDN:委托服务中的一个认证案例》[2],首次明确提出了CDN自然环境下HTTPS授权服务的验证问题,并将两种技术融合起来进行系统的软件研究。我们调查了遍布全球的20家热门CDN服务商,如Akamai、CloudFlare等,以及他们的10000多家热门网站(此外,他们也是这20家CDN厂商的客户),显示出如今在CDN中部署HTTPS的诸多困难。

起初,CDN连接点与后台管理源集群服务器之间的通信非常容易受到中间人攻击(图2):我们检测了5家CDN厂商的后台管理通信,发现虽然电脑浏览器与CDN连接点之间的通信是由HTTPS加密的,但也有厂商使用加密的HTTP与后台管理服务器的虚拟机(CDN77,CDN)进行通信。网);有些厂商虽然申请了HTTPS,但并不认证资质证书的有效性(即可以伪造所有自签资质证书的网站,有问题的厂商有CloudFlare、InCapsula等);有些厂商(如亚马逊的CloudFront)虽然规定了合理合法的资质证书,但并不认证资质证书的通用名。

其次是电脑浏览器和CDN连接点的授权验证问题。发现很多CDN厂商要求源网站提交自己的公钥资质证书和公钥,破坏了PKI安全信任的基本原则,即公钥必须严格保密,不能与第三方共享资源。虽然也有不要求客户共享资源公钥的替代方案,如应用自定义证书或共享证书方案,但密钥管理方式复杂,客户网站无法独立撤销对CDN厂商的授权,CA作为可靠的第三方也没有撤销反映授权关联的共享资源资格证书。

重点可以参考你的毕业论文全文和在奥克兰会议上报告的工作的幻灯片[2]。

2。特定攻击的示例

在实际的互联网技术中,中国高教科研网应急小组CCERT在2014年初之前就收到过类似的攻击报告,苹果在美国申请的CDN厂商Akamai的部分连接点已经遭受过类似的攻击,导致美国苹果的源网站的JavaScript网页被替换为攀爬软件免费门的 *** 作手册。我们和Akamai的技术人员确认,是他们的CDN连接点和后台管理的集群服务器应用了HTTP协议传输,导致通信被劫持,部分CDN连接点的缓存文件被环境污染。

本文最初的困难也是由HTTPS在CDN完成上的困难造成的。根据斯诺登泄露的PPT(图1),我们知道美国国家安全局(NSA)和美国情报组织GCHQ在他们的合作计划Musical中。他们还使用类似的技术来监控雅虎和谷歌之间的通信:由于靠近CDN的GFE(GoogleFrontEngine)和呈现内容的后台管理网络服务器应用不加密的通信协议或较差的安全系数,NSA和GCHQ可以绕过计算机浏览器和CDN之间的TLS,在后台立即管理加密的通信。正如图灵奖获得者、著名登录密码权威专家A.Shamir所说,“密码学通常是通过的,而不是被惩罚的。”

3。解决方案

在整个写毕业论文的过程中,大家都将这个问题告知了所涉及的CDN厂商,并与CloudFlare、Akamai等企业的技术人员有过几次交流的经历。大家反映的问题得到了所有接触过的厂商的认可。其中,CloudFlareenterprise在获得大家的毕业论文后,迅速发布了更安全的服务项StrictSSL[4],并声称该服务项可以挫败NSA对后台管理通信的监控。

众所周知,电脑浏览器和CDN前端开发的授权问题不仅仅是完成的问题。针对CDN服务项目中的HTTPS授权问题,我们在毕业论文中根据DANE[3]明确提出并完成了一个轻量级的解决方案。Dane(基于DNS的命名实体认证)是由IETF制定的标准,用于改进网站的PKI信任实体模型。大家的完成表明,在CDN的自然环境下完成安全高效的HTTPS通信是可行的。但由于DNSSec和DANE的部署并不具有普遍性,这一计划距离工业领域的广泛部署还有一定距离。大家都期待推动CDN和安全领域的进一步科研,期待更合理的解决方案。

本文第一作者梁博士也参与了CloudFlareenterprise之后的解决方案KeylessSSL[5]的开发、设计和测试。该方案没有规定客户网站与CDN共享资源的公钥,而是在CDN与前端开发的计算机浏览器进行TLS验证和密钥协商的全过程中,将整个协商过程中的信息内容按照安全无线信道发送给源网站,源网站获取会话密钥或签名后提交给CDN连接点。因为在TLS通信的整个过程中,只使用了挥舞的全过程,实物采用私钥,后续通信的全过程与源网站无关。清华计算机专业的张道伟在本科毕业设计中完成了一部分无密钥SSL。在完成过程中,修改了OpenSSL和Ngnix的部分源代码,非常复杂,对室内空房间有了很大的改善。

由于这篇毕业论文的危害,互联网技术规范组织IETFCDNI(CDNI)刚刚开始讨论CDN和CDNI互联网络间总加密流量的授权问题[/k0/][6],还没有产生最终的解决方案。由于互联网技术最初的设计原则之一是端到端,而今天很多中间盒子让互联网技术无处不在中介化,类似CDN中HTTPS的问题会很普遍,很多问题值得进一步的科学研究。我们热烈欢迎感兴趣的学者、CDN制造商的技术人员和各位一起合作进行科学研究。

段海鑫,清华网络科学与网络环境研究院研究员,互联网与网络信息安全实验室(NISL)负责人,CCERT应急小组组长,美国加州大学柏克莱分校访问学者,蓝莲花创始人。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/764884.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-02
下一篇 2022-05-02

发表评论

登录后才能评论

评论列表(0条)

保存