互联网的出现改变了世界，与之对应的赛博空间上随处可见疾驰着的数据包。理想情况下这些数据包的传输过程应该是简单的，剩余工作都直接交付给终端处理。但现实场景却并非如此，由于各类中间盒子（交换机、CDN、IPS、WAF 等）的存在使得传输过程变得越发复杂，进而造成了很多安全问题，例如广告植入、隐私泄露，此外，地下灰黑产亦是玩的好不乐乎。本次议题将由清华大学教授、清华大学-360企业安全联合研究中心主任段海新为我们带来网络端到端通信方面的安全研究，从中间盒子探测实验开始一步步揭示了缓存污染、HTTPS 中间人攻击的问题，而所有这些讲述均在实际例子的配合下循序展开，相信能够激发各位的思考。最后，正如演讲者所说互联网的魅力源于一个个自由舒展的灵魂，随着 Web3.0 时代的到来又是否能有新的创造，让我们共同期待。

——看雪『Pwn』版主BDomne

段海新，清华大学网络研究院教授，清华大学（网络研究院）-360企业安全联合研究中心主任。在网络安全领域有20多年的教学、科研和管理经验，多项研究成果发表在国际竞争最为激烈四大安全顶级学术会议上， 曾获获国际顶级安全会议NDSS杰出论文奖、中央网信办首届“网络安全优秀人才”奖。世界知名攻防战队“蓝莲花”、网络安全研究国际学术论坛（InForSec）的联合创始人。

谢谢主持人的介绍，谢谢老朋友段钢的邀请。能够在看雪安全开发者峰会这么专业的社区做报告是我的荣幸。

我今天与大家分享的题目是“端到端通信当中的中间盒子”。端到端的原则可以说是互联网设计之处专家们非常珍视的原则；但是随着互联网的发展，中间出现了很多盒子，比如防火墙、CDN、缓存等等。这些中间盒子一方面给我们的网络访问带来很多好处，比如提高了用户的体验、保护了用户的安全；但是同时，它也给我们带来了一定的风险。

首先，我们先初步了解一下大概的风险是什么。这是我2015年在美国开会时上网的一个截图。这是世界安全领域顶级的学术会议Security&Privacy，酒店在访问我微博帐号时插入了酒店的广告。还有下面的这个情况，在手机上网的时候，有时会看到运营商给你弹出的流量球、运营商的广告。还有在WiFi环境下，有的朋友发现一个干净的应用不知道为什么被插入了一个令人非常难堪的广告。

也许大家听说过几个运营商和网站对网络流量的劫持深恶痛绝，于是在发起了这么一个倡议书，几大公司联合发表了一个声明，抵制流量劫持。当时在看这个声明的时候，发现这个声明也问劫持了。

下面我们就看看这些广告究竟是在哪里注入的。当然，这些攻击并不一定来自于邪恶的攻击者，有可能只是运营商的广告。但是，可能这些插入广告设备的运营者可能并不清楚，这些基础设施存在很大的安全风险。

端到端的原则与中间盒子

我们回顾一下端到端的设计原则。互联网先驱者之一MIT教授DavidClark在八十年代总结了先驱者们的观点，然后写了一篇关于端到端原则的论文。所谓的“端到端”最重要的是几条，一是复杂的终端，二是简单的网络。这样，大多数的功能都应该在终端上实现，而网络尽可能的简单，它的功能只是把这个数据从源转发到目的，不应该做过多的修改，甚至不加修改。比如，文件传输协议中，中间节点不应该做太复杂的功能，比如差错的校验、重传这些功能应该在端系统上来做。特别是对于安全这样的功能，更不应该放在中间的节点上。加密和解密这些工作在中间节点上是不可信的，因为安全通信本来假设网络和中间节点就是不可信的，中间节点解密再加密破坏了数据传输的保密性。

但是互联网的发展从来不是按照先驱者们所设计的原则来进行。在现在的互联网当中已经有很多中间盒子，比如地址转换（NAT）。当时互联网体系结构委员会为地址不足所设计的方案是IPv6，NAT在当时互联网体系结构委员会的强烈反对下野蛮生长，但是NAT今天到处都是，IPv6的部署至少在中国仍然不是很普遍。

互联网体系结构委员会（IAB）在后来的体系结构原则的一份RFC中说，过去的所谓“原则”只是过去经验的总结，不能作为教条。互联网上唯一不变的原则，就是适应不断的变化。

针对逐渐发展起来的各种网络中间设备，2000年前后，David Clark的学生、UCLA的张立霞教授创造了中间盒子（Middle Box）这个词，她总结了互联网上经常出现的中间盒子，大概分成这么几类：一类是为了提高网络性能，比如DNS的缓存、HTTP的代理、透明的代理以及CDN等；第二类是实现地址转换的，比如IPv4下的NAT、IPv4和IPv6之间的地址转换设备；第三类是为了提高安全性的，如防火墙、IPS等，CDN也一定程度起到安全作用。但是张丽霞教授当时的报告并没有提到这些中间盒子可以用来其他的目的，比如用来赚钱、用来钓鱼等这些攻击行为。

一个探测中间盒子的实验

为了证实互联网上这种中间盒子的存在，我们在今年年初做了一个实验。首先，我们自己注册了一个域名，搭了一个web服务器，它只有一个非常简单的静态页面。然后通过世界各地的终端，主要是手机端，向我们的web服务器发了一个HTTP请求，终端这边把web页面拿过来之后，再把这个页面压缩一下传回服务器。这样我们在服务器上就可以看到请求和响应是否被修改。

实验涉及到3万多个IP、298个自治系统（AS）、45个国家，绝大多数还都是在中国。

我们分析了3万多个请求，发现有1200多个发往服务器的HTTP请求中增加了一些我们原来没有看到的Header，有22个返回给客户端的HTML页面被插入了网站以外其他的内容。请大家忽略左边的终端类型，手机厂商其实跟这种注入没有关系。这些中间盒子把用户手机端的一些信息插入到HTTP的请求里，也就是说任何一个网站的运营者者，能够看到来访用户相关的信息，甚至手机的号码。你可以拿它来做什么？网站的精准营销，你如果浏览的一个医院，也许马上就有人给你打电话了。刚才说到，有22个页面被注入了广告，包括运营商自己的广告和其他第三方合作的广告。

HTTP透明缓存污染攻击

这些都是中间盒子的运营者合法插入的内容。有没有可能这些中间盒子被第三方用来干别的事情呢？我们的一项研究就是分析这些中间盒子在处理歧义的HTTP Header时所面临的风险，其中一个攻击可以造成透明代理的缓存污染。

下面看一个演示，如何攻破美国国家安全局的网站NSA.GOV，实际上攻击的是作为透明代理的中间盒子。因为很多用户共享这些透明代理的缓存，只要攻击者把自己的内容放到缓存里，就可以攻击所有共享的用户。这个演示中页面的URL是不存在的，因为如果这个界面存在的话，那我们就构成一个真正的攻击。这个试验是Planet-Lab实验床中新加坡国立大学的一个节点上完成的，从那台计算机上发起了一个HTTP请求，大家看看得到的响应是“302”，这个URL在NSA.GOV上是不存在的。

然后我们在这台机器上运行自己的攻击脚本，向我们控制的一台服务器attacker.com发一个HTTP请求，但这个请求是我们刻意构造的非常畸形的请求，它把新加坡国立大学校园网的透明代理给污染了。校园网的透明代理使用了15个节点做负载均衡，所以必须把这15个节点全部污染掉。现在再来访问那不存在的URL，可以看到我们注入的内容。注意这只是个演示，我们完全可以污染一个已存在的页面，并且在其中插入恶意代码或者钓鱼的信息窃取用户敏感信息。

下面看一下这个攻击是怎么进行的，在端到端的模式下这种攻击是不可行的，我们没有办法攻破NSA的网站，否则我也不敢站在这了。早期的HTTP协议只允许一个IP上一个Web服务，这种情况下不会有任何的歧义。但是有了虚拟主机、有了CDN之后，你向一个IP地址发起一个连接，可能后面有多个web服务器虚拟主机，中间还有很多的中间盒子、缓存或者CDN。如果我们构造这样的畸形请求：在GET后面URL路径中指定的名字是a.com，后续Host头指定的是却是b.com，甚至可以再加一个c.com，中间节点和目标网络在解释这个目标时，究竟应该访问哪个？是a、b，还是c？

我们查阅了互联网标准协议RFC，里面有一些是比较明确的，有一些是比较模糊的，但是到具体厂商的实现上又是五花八门的。因为RFC最初的意思是征求建议，它并不是强制性标准，也没有一个认证机构去认证一下这个产品是否符合RFC的标准。所以中间的设备在处理这些请求的时，大多数情况下是尽可能的转发。

但有了中间盒子以后产生了各种各样的歧异，一个简单的场景下Client发一个这样的请求，里面有两个Host headers，下游的这个DownStream它认为你访问了a，服务器认为你访问的是b。标准规定应该是什么？我们检查了RFC两个时期的版本，其中最新的7230应该是2014年。这些标准里对出现两个Host Header的请求都是不允许的。但我们考察了主流的20多个HTTP协议不同的实现，发现绝大多数的实现都是接受这样的请求、选择第一个Host header。对于选择接受最后一个Host Header的实现，我们也不难构造一个有歧义的请求。

刚才说的HTTP请求中，绝对路径URL中的主机和Host Header中的目标不一样时，HTTP的标准应该是怎么规定的呢？两个时期的RFC里都规定应该是绝对路径优先，但是我们看到实际上世界最大的CDN厂商Akamai是不遵守标准的，它是优先检查Host Header，其他厂商绝大多数是遵循RFC的。利用中间盒子对Host header处理不一致性，我们在绝对路径中指定的是NSA，但在Host Header指定的是Attacker。广为流行的开源代理软件squid把请求发给了attacker，attacker可以在这个响应里携带恶意代码。但这个响应达到的时候被错误存到了NSA.GOV缓存里。其他用户在访问NSA.GOV时，从缓存里拿到的是attacker放到缓存的内容。

我们测试了20多个HTTP的实现，包括主流的安全产品和开源代码。把这些不同的场景作为组合，我们测量出202种场景是可能被攻击的，除了我们刚才看到的缓存污染以外，还有绕过防火墙攻击。涉及到的产品包括squid，这是最广泛的开源软件，包括Windows、Akamai、PAN等主流的防火墙，都可能被防火墙绕过攻击（我们跟PAN、华为等公司沟通过，目前这些问题都已经解决了）。

刚才的演示需要在受害者网络中有一个机器、一个帐号，但这个条件并不是必须的。我们后来又做了一个实验，通过购买广告的方式，把一个测试flash的脚本推送到成千上万的用户桌面浏览器里，发一个类似我们演示中的HTTP请求。通过这个测试，我们发现全球98%的透明代理是可以被污染攻击的。

加密协议HTTPS中的中间人问题

刚才看到这个攻击影响的是HTTP，它没有加密、可以被缓存，所以可以被攻击。那么，是不是加密以后就没有问题了呢？同样还是在2015年美国那个学术现场，我访问了一下Facebook，由于Facebook使用https访问，酒店没有办法注入广告。是不是可以放心了呢？没错，HTTPS的设计的确可以实现端到端的数据加密、完整性保护和身份认证，中间人是没有办法攻击的，而且即便是存在HTTP Proxy的情况攻击也没有办法，因为HTTPS在TCP链接之上又建立了一个端到端的加密链接。

但是，因为有这个中间盒子的存在，攻击还是有机会的，多数网站的访问不是一个HTTPS的链接，我们的浏览器还可能会发出HTTP的请求，因为有这个HTTP的存在，我们可以构造下面这样的攻击。银行的网站虽然是HTTP的，如果没有实现HSTS，我们可以通过中间盒子让用户访问发起一个HTTP的请求。然后，向这个HTTP的连接里注入一个cookie，然后把HTTPS的cookie替换成攻击者的。它根本的原因是浏览器在处理这个cookie的时候，以前的标准是HTTP和HTTPS的cookie它认为是同源的，以至于我们可以通过HTTP把HTTPS的cookie给覆盖掉，用户在访问银行网站时使用的是攻击者的cookie。这种攻击可以造成用户隐私泄露、HTTPS会话被劫持等等，比如，我们在2014年的时候可以劫持Gmail的通信，把Gmail的好友列表替换成攻击者的，让用户以为攻击者就是受害者的好友从而上当受骗。

另一个演示，也大家可以从有的网站上看到，我们可以劫持用户的网络购物支付过程，我们对中国的几个金融机构都做过测试，这个攻击都是成功的，当然我们都通知这些机构。现在展示的是对美国银行的攻击，用户https加密协议访问时，中间人可以向他弹出这个窗口，这个Javascript是我们注入的。

这个问题的根源在于浏览器在处理cookie的缺陷，但标准就是这么规定的，并不是浏览器厂商的问题。后来我们的研究成果在顶级学术会议USENIX Security上发表了，谷歌公司根据我们的论文做了一个调查，后来谷歌修改了浏览器。2015年Google还向IETF提交了标准草案，要更新cookie的标准。目前这个标准还是草案阶段，但我们测过几个主流的浏览器，都已经修改了，尽管它没有成为正式的标准。我们刚才看到的是中间盒子可以通过cookie的注入影响到https中的加密。

另外一方面，CDN这样的中间盒子已经把TLS的端到端通讯截断了，浏览器看似访问的网站使用了https，但是这个安全连接仅仅到CDN就已经终止了，从CDN到后端原始网站究竟使用的是不是HTTPS这种加密的协议呢？如果是，它实现的是否正确呢？我们对这个问题也做了研究。

2014年我们测了几个主流的CDN厂商，亚马逊的CloudFront前端浏览器看到的是使用HTTPS，但从CDN到后端的通讯中有两个使用的是HTTP，在后端就可以实现中间人的攻击。Cloudlare是跟百度合作的，虽然使用了HTTPS，但是它不验证证书的合法性，用一个自签名的证书也可以通过。这样中间人攻击易如反掌，有些厂商虽然它要求有一个合法的证书，但它不检查这个证书的名字，也就是说只要随意申请一个合法的证书就可以实施中间人攻击了。

这个攻击在现实中也是存在的，NSA就是用这种方法攻击了Google公司，用来破解Gmail使用HTTPS。看这张斯诺登泄露出来的PPT，Google的GFE节点类似于CDN，几乎所有的服务都通过GFE达到后端的原始网站。那时，从GFE到后端的原始网站是不加密的。NSA可以在Google所在的数据中心部署流量分析的设备从而监控用户的邮件。这样的攻击我自己见到过。

2014年甘肃和山东的一些大学给我们报告，访问苹果的网站上的一个脚本，看到的却是一个翻墙软件的使用手册。我们后来向Akamai发了邮件报告了这个问题，最后它们确认那涉及到的节点是被污染的，虽然访问苹果公司前端使用的是HTTPS。

我们把发现的这些现象报告给主流的CDN厂商，它们都积极地反馈，其中CloudFlare在一个月以内推出了新的服务叫StrictSSL，后端也使用了严格的验证，在他们发布的Blog里特意放了一个图，说因为有了StrictSSL，NSA再想从后端监听通信不再是可能的了。可以说，我们的研究防止了NSA对普通用户的攻击。

除此之外，对TLS拦截还很多，你电脑上的防病毒有可能把连接已经劫持了。有些企业的TLS网关，为了业务的需要检测用户上网的一些行为，通过在用户电脑上安装自签名的CA根证书，就可以伪造任何一个网站的证书，你的TLS通信再企业的边界被解密，然后重加密了。

关于这方面的研究，我们在这几年做了很多，包括HTTPS在CDN当中的部署问题、Cookie完整性问题等。我们还专门研究了CDN本身的安全问题。CDN虽然是提供安全性保护的，但我们的研究表明，通过CDN厂商之间实现的不一致，可以把这些CDN串连起来，形成一个无限的循环，通过这个无限的循环大量消耗CDN厂商的带宽和计算资源，从而构造一个对CDN本身的DDoS攻击。这是我们2016年发表在NDSS上的一项研究成果，被评为当年的杰出论文。缓存污染是2016年发表在CCS上的，刚才已经介绍过其中的部分结果。除了对于Web以外，我们对DNS中间盒子也做了很多研究。下个月在USENIX Security我们要发布一项研究成果，就是全球各地的对用户DNS请求劫持的行为。

总结

最后，简单做一个总结，中间盒子虽然提高了网络性能和安全性，但它也带来了一定的风险，增大了攻击面。比如，原来只能攻击那个目标网站，现在攻击中间的那个盒子就可以了。我并不主张运营商把中间盒子都去掉而退回到原始端到端的模式，现在复杂的应用是原来简单的模式没办法支撑的。我只是说，新的应用设计过程当中应该充分考虑这些中间盒子的存在，同时，管理者也应该清楚，这些看不见的中间盒子有可能也是攻击目标。

另外，我们通过这些年的研究深深体会到，互联网的“标准”，远远不像想象中的那么标准，即一批专家制定了标准，所有厂商都严格按照这个标准来执行。其实，我们看到的大多数标准是厂商甚至某个人在没有标准的时候自己实现的，所谓的标准只是当前被共同认可的最佳实践。现实互联网中，许多实现跟标准不一致。互联网的标准是不具有强制性的，也没有一个说一不二的权威强制所有实现都必须符合它所制定的标准。当然，正是互联网允许这种百花齐放和不一致的存在，才体现了它的生命力和创新。就像刚刚结束的世界杯上，互联网厂商和个人就像巴西队的球员，每个个体都是一个自由舒展的灵魂，没有办法把他们打造成为一家严丝合缝的一辆战车，这正是互联网创新的源泉、互联网的魅力所在。

以上是我想跟大家分享的，谢谢大家！

声明：本文来自看雪学院，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。