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

　　问题分析与测试

　　目前主流网站都依赖HTTPS（HTTPover 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 Symposimon Security & Privacy）发表了论文WhenHTTPS Meets CDN：A Case of Authenticationin 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。

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

　　具体细节可以参考论文原文和Oakland会上所作报告的Slides[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 typicallybypassed，not penetrated.”

　　解决方案

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

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

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

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

　　（作者单位为清华大学网络科学与网络空间研究院）

　　参考文献

　　[1]NSA infiltrates links to Yahoo.Google datacenters worldwide ， Snowden documents say.https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centersworldwide-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，in2014IEEE Symposium on Security and Privacy（SP），2014，pp.67-82， PDF and PPT Download： http：//netsec.ccert.edu.cn/duanhx/archives/1803

　　[3]Nick Sullivan.Introducing Strict SSL：Protecting Against a Man-in-the-Middle Attack onOrigin Traffic.https://blog.cloudflare.com/introducingstrict-ssl-protecting-against-a-man-in-the-middleattack-on-origin-traffic/

　　[4]P.Hoffman and J.Schlyter. The DNS-BasedAuthentication of Named Entities（DANE）.TransportLayer Security（TLS）Protocol：TLSA，RFC 6698https://tools.ietf.org/html/rfc6698

　　[5]Keyless SSL，https：//www.cloudflare.com/keyless-ssl/

　　[6]S.Slovetskiy.Approaches to HTTPS-basedRequest Routing and Delegation.https://datatracker.ietf.org/doc/draft-slovetskiy-cdni-https-delegationapproaches/