对初次接触侧信道攻击这一概念的人，可能多少会有些困惑，实际上其含义有点类似于旁敲侧击，即通过事物的关联性来间接印证某一事实。在我们熟知的网络攻击领域，中间人方式可谓屡试不爽，战果也甚丰硕，由其造成的危害是比较严重的，那么非中间人方式的攻击呢？本次议题将由加州大学河滨分校的钱志云教授为我们带来有关网络侧信道方面的分享，在相关研究背景的铺陈下，演讲者分别详述了基于全局 TCP 计数器、共享限速器以及 WiFi 协议在内的多个 TCP 侧信道漏洞变种，其中不乏首次公开的利用技术，足见非中间人方式的网络劫持也是大有可为且隐蔽性更佳。如果你想深入侧信道攻击的学习，那么本文不失为一篇很好的序章。
——看雪『Pwn』版主BDomne
钱志云，加州大学河滨分校 (University of California, Riverside) 副教授。他的研究兴趣在于网络，操作系统，以及软件安全。其中涉及到TCP/IP协议的设计与实现，安卓操作系统的漏洞挖掘和分析，以及侧信道在网络系统领域中的安全性研究。获得GeekPwn 2016最大脑洞奖和GeekPwn 2017优胜奖。
大家好！先讲讲我个人的研究兴趣。刚才说到侧信道，侧信道是一种比较新型的漏洞，总体来讲，我这个人因为性格的关系，比较喜欢挖漏洞，比较喜欢做攻击，很多研究方向是漏洞挖掘和漏洞利用。
侧信道这个漏洞，这个时候很多人都熟悉了，我们已经做了很多年。侧信道被大家最为熟知的就是最近英特尔CPU出的问题，这个漏洞发现，一旦有了侧信道就很难修复，而且这个漏洞的影响力很大。对于我来说，侧信道的研究主要是在网络协议的侧信道，据我所知，这个方向做得是比较少的。
举个大家都知道的例子，比如在玩狼人杀和杀人游戏时大家都听说过一个词，这个词叫“场外信息”，什么意思？比如大家在闭眼的时候，你旁边有一位菜鸟他睁眼了，睁眼以后指认时动作就有点大，结果一不小心出了点动静，有点声音或者有点振动，你坐在旁边的人能够感受到，这叫“场外信息”。还有法官说“请杀手睁眼，请杀手指认。”这个是对着杀手说的，声音有方向性，大家闭眼能够感受到杀手在那边，这都是场外信息，说白了就是侧信道。
我们为什么要研究TCP？这有一定的机缘巧合。当年我做研究的时候，我老板是做网络出身的，我不能不做网络，但是我又不喜欢网络，因为网络发展得很成熟。TCP是古董级，一旦出现漏洞的话威胁比较大。另外，大家觉得TCP本身已经没有什么变化了，但是我们看一下这个结果，我们去爬了github上每个月的数量，每个月网络协议站一直都在有更新，而且还比较稳定。这些更新是干嘛的？加一些新功能，比如TCP发stoken（音译），原来TCP要三次握手，现在改成第一个包发出去里面就直接带数据，因为做安全的修复或者维护。虽然看起来TCP是不变的、很陈旧的，但是里面有很多实现上的改动，甚至规范层面的改动。
今天介绍TCP网络侧信道的攻击，需要先介绍一下这个攻击的简单背景知识，然后讲四个不同的TCP侧信道的变种，这里包括去年11月份GeekPwn硅谷站做的最新攻击，这个攻击利用了几乎无法修复的漏洞，一会儿跟大家讲什么叫“无法修复的漏洞”，有听说过什么洞是无法修复的吗？我从头把这个历史介绍一下。
Background on Off-Path TCP Exploits
先介绍一下背景知识。网络攻击其实很简单，我们大概可以归成两种类，一种是中间人攻击，中间人攻击很简单，中间人这个攻击者在通讯路径上可以把A和B的消息全部都劫获、修改、丢包，甚至伪造APP。这种攻击是很强的，但通常来说没有那么容易实现。刚才黄涛介绍了用第三方的WiFi，有一些场景是可以做的。或者把路由改掉，有一些技术，但那些技术的影响力和使用范围是有一定局限性的。或者你是政府，或者你是运营商，当然你可以做中间人，但通常它们不会做黑客做的事情。
对于中间人来说，一般的防御措施多少是加密，加密有它的开销代价，比如你要去维护它的密钥、证书，那些东西也会出现安全漏洞，也有安全隐患，不是完美。而且有的时候我们发现，在有些情况下，这个网络如果是加了密的话，看起来是修复了一些漏洞，但其实有的时候是有些功能受到影响的。比如在移动网络里，突然有一个视频火了，每个人都去看这个视频，如果这个视频是加密了的，移动运营商就没办法帮你在网络层做缓存，否则它可以节约很多带宽。我们在2016年就看到整个互联网有一半以上的流量是不加密的。
第二种常见的攻击模型在网络里是非中间人，非中间人怎么攻击？现在这个攻击者不是在通讯路径上，A和B发什么消息，非中间人看不见，他没办法劫获包，也没办法丢包。它唯一能够做的就是伪造A给B发消息，因为这个互联网是允许的，就看谁的消息先到，通常来说，在网络协议里谁的消息先到就会被接受，只要这个消息是合法的。通常情况下这种防御措施是什么？我们叫它challenge-response，就是a跟b通讯前先要交换一个随机数，这个随机数在将来每条消息里都需要被附带，非中间人攻击者看不见这个随机数，就算能够伪造a给b发，b也不会收，这个道理很简单。但是不是这种保护机制就安全了？其实不是。通过侧信道方法，有很多种办法可以去猜到这个随机数。非中间人攻击的危害就大多了，因为它不需要跟你连一个WiFi、跟你离得很近，这个攻击在互联网上任何一个角落都可以做，只要你的网络伪造原ip地址。
在TCP这个协议里就集成了challenge-response机制。TCP三次握手这个机制，开始客户端要发一个，建立连接，生成初始的随机序列号，我们叫它x，这个包到服务器上，服务器回一个x+1，以免我收到了你这个challenge并且响应了challenge。但客户端和服务器端都生成了随机数，这时客户端会干嘛？要回这个y+1，证明收到了两次y三次握手结束时，客户端和服务器端都确认对面不是非中间人，因为非中间人看不到这个，就没办法回复x+q或者y+1。
但这个简单的TCP序列号的问题，在历史中出现了很多披露，大家都把TCP序列号作为大家要争夺的东西。最早在1985年时，就有人发现初始的序列号这个x和y其实是不随机的，也就是说只要你看过一次x，下一次过若干时间时再去看，就能预测出将来的x是什么值。为什么这样？因为初始序列号是由一个全局的计数器，比如每过多少微秒这个计数器就加1，你看过一次x之后，就算过了多少时间，将来新的初始序列号就能够预测出来。就是这样一个简单的漏洞，在1995年时被美国非常有名的黑客利用起来了，他拿这个做了什么事情？他拿这个伪造了一个客户端，跟微软大厦的服务器建立连接，把美国的机密文件偷出来了，他也因为这个事情付出了坐牢的代价了。但也挺惊讶的，这么简单的漏洞居然就能够满足这个事情。后来大家修了，现在都是初始的x和y，非常随机。
到了2007年有人发现，在Windows场景下用可以用IDID的侧信道可以猜出来序列号，当时他们只针对Windows，而且需要花几个小时时间才能猜出来，所以基本是不可用的。2012年时我们看了一下这个问题，发现有办法几秒钟就可以把序列号猜出来。2016年在GeekPwn做了一个条件非常弱的攻击，全世界任意给我两台机器，告诉我两个任意IP地址，我们可以远程劫持连接。2018年在下个月要去做报告，也是GeekPwn去年硅谷站做得攻击，是一个几乎无法修复的漏洞，也是用来劫持TCP的。
Malware-assisted
（视频播放）这个攻击是说安卓的应用程序没有任何权限，它唯一能够做的就是网络连接，这个程序跟外面一个非中间人攻击者可以做协同，相当于里应外合。这个攻击可以劫持手机上所有的TCP连接，我们这个demo当时是把Facebook的连接劫持了。比如你去上Facebook，这时你看到的页面是我们篡改的页面，而且这个软件是完全不需要任何权限下做的。
接下来讲讲这个攻击大概是怎么做到的。我刚才说到，这个攻击模型需要里应外合，这个攻击模型比较有趣，之前没有什么人想到。我们的目标是通过这个攻击模型，去劫持手机上任意的软件所打开的连接。具体我们要做什么事情？要得到什么信息才能够做这件事情？有两个，第一个，Facebook的连接ip地址和端口号，拿到这个以后就知道TCP连接的序列号，拿到序列号以后我们就能够伪装Facebook给手机发消息，TCP的序列号通常是连续的，这个包才能够接收，如果序列号差得很远，这个包就算到了手机端也会被丢包。我们的任务是精确的猜到它下一个序列号，这个值范围非常大，因为序列号是32位，猜起来很困难。刚才说到有两个信息，第一个信息是IP地址和端口号。这个信息很好拿，因为据我所知，所有的操作系统都不需要权限就可以调netstat命令，可以把当前系统里所有的TCP连接都读出来，这里给了你IP地址和端口号，你看到现在有一个Facebook连接，我可以劫持。
拿到TCP序列号之后干什么？我们大概的思路是这样的，非中间人伪造Facebook会猜这个序列号。在猜的过程中期望通过某一种手段、某一种侧信道，这个恶意软件在后台，它可以给我们提供一个反馈，告诉我们是猜对了还是猜错了，大概这个想法。我们具体怎么做？我这里讲四种攻击变种：
第一个变种，它是一个防火墙导致我们能做的攻击，通常防火墙不都是提升安全的么，但这个场景下防火墙帮了我们的忙，有点讽刺的意味，因为如果没有防火墙的话我们这个攻击做不了。这个防火墙做的事情也很正常，它做了什么？TCP三次握手结束的时候有x和y，这个防火墙会说，将来你从客户端或者从服务器端来的包的序列号一定要跟y和x很接近的序列号才放你过去，否则就丢包。这个想法也很合理，如果序列号要连续，终端才会被接收，才有价值，否则就算到了终端也被丢包。比如手机端有一些不合法的包，你提早把它丢掉，可以帮我们省电，因为网络很耗电，收没用的包浪费电，也浪费流量。这个防火墙的设置很合理的，但恰恰因为这个防火墙导致我们可以做这个攻击。
怎么做的攻击？非中间人可以猜序列号，如果猜错的话这个包就过不了防火墙。但如果猜对了，根据包能够达到手机端，到了手机端之后，后台的恶意软件是不是能够通过某一种方式观察到，现在是收了一个包还是没收包，是不是有可能有这种机制、侧信道让我们判断出来？我们判断当前是收包还是没收包。给大家举个例子，怎样判断？比如我们可以看CPU的使用率，因为当你收到一个包的时候内核需要CPU的时间去处理这个包，这个时候CPU就在用。在用和没在用，恶意软件能够在后台观察出来，比如自己不停用CPU的资源，就能够观察到。当然，这个CPU资源使用率是噪音很大的，我们实际当中没有用这个，但这是一种方案。
具体我们用了什么方案？我们用了操作系统当中所带来一系列TCP的计数器，这个计数器是全局可读的，而且是不需要任何权限的。到今天为止，据我所知这，所有的操作系统都是这样设置的，是公开的，只要你登陆到机器上，不需要权限就可以看。这些计数器之所以可以看，因为它是全局的，不是某一个连接。手机或者操作系统从上一次启动到现在，一共发了多少包、收了多少包，有多少重盘，有多少包是出错被我丢掉的等等。大家看看这个计数器有没有+1，+1就是刚才那个包过了防火墙，所以手机才会收到这个包+1。如果没收到这个包，计数器不变，后台恶意程序协同时只要读一下计数器，跟外面汇报一下现在是+1了还是没+1。这个计数器噪音也很大，因为后台有其他软件同时在跑。其实说得也没错，我们实际上也没有用这个计数器，因为这个计数器确实噪音大。
我们用的是低噪音的计数器，有一些包收到是错误的，这个包会被丢掉，丢掉的与此同时，一个相应的错误计数器也会增加，这个计数器是低噪音的，因为网络发包不太可能收到错误包的，而且防火墙也不会检查所有的错误，因为这个代价太大，它只是比较重要的检查，比如校验对不对、序列号对不对，其他东西它不看。我们可以构造一个有错误的，比如时间出了错误的包，导致防火墙检查序列号对了，等到这个包到手机端会触发一个相应的错误计数器的增加，这样我们有一个低噪音的反馈。
大家可能会想，这种攻击是不是看起来防火墙帮了我们？但这个防火墙是不是真正通用的常用的防火墙？这个问题我们还不知道，所以我们去研究了全球范围内，包括中国、美国、欧洲的各大运营商，去看有哪些运营商部署了这样的防火墙，发现33%都有这个防火墙，显然是非常流行的。再看了哪些防火墙厂商做了这些事情，全球领先的防火墙厂商基本都有这个功能，显而易见大家都认可这个功能，这是个好主意，不然不会去实现检查序列号的功能。我后来在国内做报告时，发现国内有些厂商也做这个事情，到现在为止都还在做，大家不知道有攻击的可能性。
我们在美国时跟ATNT，它相当于中国移动这样的运营商，在它们那里做实验发现有这样一个问题，ATNT找到它们的防火墙提供商，checkpoint是以色列的一家公司，它们承认了确实有这个路径，但它们没有好的办法，就把这个功能给关了，既然检查序列号有问题，那就不检查了呗，这体现了“多做多错”。它运气不错，这个还可以关，如果关不掉的话就要召回了，风险更大了。刚才讲到了第一个攻击变种。
第二个攻击变种，刚才那个攻击是有防火墙帮忙才能够做得到，那没有防火墙帮忙还能不能做这样的攻击？后来发现还是可以做。还是用同样的TCP全局计数器，只不过这次有些特殊的计数器很有趣，比如有一个计数器跟TCP的业务逻辑有关，当我收到一个TCP的包，它的序列号比我期待的序列号要小，这时候证明网络有问题、有重传，所以TCP的业务逻辑告诉我要进入Quick ACK Mode，当我收到一个TCP序列包的号比我期望大的时候这个计数器就不用增加了，就不变。这个业务逻辑其实是TCP内部状态通过计数器暴露给了用户，等于所有的软件都可以。如果我能够判断出这个序列号是小还是大，是不是挺危险的？我这个非中间人攻击者可以随便猜一下序列号，猜小了这个计数器就增加，猜到了这个计数器就不变，这就可以让我们做一个搜索，做二分查找，给大家一个“0-100间的数让大家猜，猜了之后告诉你猜大了还是猜小了。序列号是32位，也就是说我们猜32次就可以猜到它希望的那个值。
而且我们还做了优化，做攻击猜8轮就可以猜出来，非常快！那个攻击是1秒钟就能够搞定。后台有一个恶意软件，外面有一个非中间人攻击，在1秒钟之内可以把这个Facebook连接劫持了，一旦你打开Facebook网站就被劫持。
这个问题不是某一个操作系统的问题，不是安卓或者Linux才有的问题，苹果、FreeBSD都有这个问题，FreeBSD都有这个问题，我们汇报了这个问题，它们反应非常快，像Linux很快给了解决方案，这个解决方案不完整，只解决了一小部分问题，到今天为止这个计数器还在，大家做反馈的话还是能够猜到当前连接的序列号。
FreeBSD跟我们交流的也很多，讨论了好几个方案，要么是兼容性有问题，要么是性能有问题，最后一个方案都没用。我们2012年给苹果发了一封邮件过去，然后就石沉大海了，有一封自动回复说“我们收到了你的邮件”，有趣的是2017年我的邮箱突然来了一封邮件，说“漏洞给你修了”，我已经忘记了是哪个洞，因为已经过了5年时间了，后来想起来是当年那个洞。这个事情让我觉得应该是因为侧信道这个事情原来在工业圈不被重视，现在侧信道越来越多被大家所认可，所以他们翻bug列表时发现了这里还有一个侧信道的问题，就顺便修一下吧。唯一没有问题的操作系统是Windows，为什么是Windows？因为Windows没有特殊的计数器来暴露内部的TCP的状态。这说明了什么？“多做多错”。
Pure Off-Path
接下来开脑洞的时候到了，2016年时我们看到之前攻击都需要有恶意软件在客户端，现在没有恶意软件，是不是还能做攻击？只要全世界任意给我两台机器，任意两台TCP告诉我，我们都能够给你劫持了，而且我是非中间人，中间人劫持没什么了不起的。怎么做？你任意给我两台机器，首先知道它们之间有没有建立连接，假设有的话还要知道TCP的序列号，正向的和反向的都需要知道，也就是刚才说的x和y。这个我们拿了一些奖。
如果这个攻击能够做得出来的话，是不是威胁很大？举个例子，我知道在座各位家里的IP地址，然后我跟你连个QQ，是不是可以不停的在测你现在访问哪个网站？这样你的隐私就已经没有了。而且我知道你的序列号，能知道你在网上停留了多少时间、交换了多少字节，大概能够推断你在网上做了什么事情。再然后，我有了序列号，还可以在TCP这层强制把连接断开，可以做拒绝服务。再然后，如果这个连接是不加密的，我们甚至可以直接伪造服务器或者客户端给对面发包，就相当于可以做远程劫持。
刚才大家看到那两个攻击，所有的侧信道从本质上来讲，都是因为一个重要的必要条件，就是攻击者和被攻击者之间一定共享些资源，这样才有侧信道的可能性。之前共享的资源是全局的TCP计数器，所有的软件都可以，被攻击的软件的连接受到一些影响的话，它那个状态也会体现在全局计数器上，你有一个软件可以随便读出来。但是到了这里，也有一个共享资源，这个共享资源比较有趣、比较特殊，是平常一般想不到的。
我们现在调转一下枪头，看一下服务器上的共享资源，它有一个东西叫“限速器”，是限某一种包，比如在每秒钟之内只能发100个，这种包是在极端情况下才会被触发的，几乎是在被攻击才会触发的，这些包发多了是浪费带宽，没必要发太多。什么是？你已经跟我建立了连接，这时你又给我发一个，再建立连接，我说“哥们，咱俩已经建立好连接了，你又发一个是什么意思？”我回一个challenge回去，这个challenge限制了每秒最多100个。这个限速器是全局的，所有的连接共享这样一个限速，假设跟客户端的连接发了challenge，同秒给攻击者发challenge的时候就只能发99个，连接加起来在1秒钟只能发100个，所以它是共享资源、共享限速器。
共享限速器怎么帮助做侧信道、做远程TCP连接？看起来这么小的一个东西，怎么做到远程的TCP连接？我们的第一个动作，判断一下客户端和服务端有没有建立连接，有的话后面再说。这个非中间人会发一个伪造的TCP包，这个包假装是从客户端来的，而且这个包里需要猜一个原端口号，因为目标端口基本是定的80、443，假设这个原端口号正好对应客户端和服务器端建立一个连接，这时候服务器回一个challenge，说“哥们，咱俩已经在这个端口建立连接了，又发了一个过来？”这种情况下，攻击者用自己的连接想办法去触发challenge的时候最多只能收到99个，因为另外一个是在客户端那个连接上回复过了。而且巧妙就巧妙在服务器回给客户端的那个challenge是非中间人看不到的，间接的判断服务器刚才有没有回复challenge。
这个例子看完，我们马上就懂了，如果还是同样的存在，原端口号是错的，也就是说它没有当前的连接，是不是这个服务器就不会回challenge？它要不回的话，攻击者用自己的连接能够观察到100个challenge回来，猜对了能看到99个，猜错了就能看到100个。只要去看最后是99个还是100个，这个攻击就成功了，就知道客户端和服务器端有没有连接了。
大家可能会想，是不是1秒钟只能猜一个端口号？太慢了！一共1万多个端口号默认。其实不用，我们每秒钟可以猜5000个，为什么？因为只要这5000个包猜的是不同端口号，有一个猜对了基本会有challenge回来给客户端，我知道这5000个当中有1个是猜对的，之后再做二分查找，看看这5000里面是这2500个猜对了还是那2500个猜对了，所以很快就可以猜出来。
我们做的攻击只要不到10秒钟时间就可以把是否建立连接判断出来，30秒钟时间可以把序列号猜出来，再不到10秒钟时间可以把反向序列号猜出来。我们2016年GeekPwn做了这样一个攻击，假设你上一个网站，这个网站有长连接，不停的去后台看有没有更新，我们把这个连接劫持以后可以往里面注入，可以注入假的注册登陆方，这时请你输入iPad或者iPhone用户名、密码，就可以跳到这些信息。这个问题根本上并不是Linux实现的问题，只不过是因为TCP的规范在2012年就规定了challenge，以及它推荐了需要有一个限速器，当我们这个工作做完以后，TCP规范组讨论反思了，还加了修订案，限速器不能随便玩，一不小心就玩坏了。
解决方案是两种，一种是加噪音，100替换成150、200，随便变，第二种是限速器不要做全局的。当时Linux的创始人24小时在线，很快给我们打了补丁回来，说让我们这样加噪音，虽然他的编程能力很强，但其他不行，那个补丁还是不安全，所以我们帮他修了一下，修好了。
Unfixable WiFi timing
现在讲最后一个问题，这个问题是几乎没法修复的。刚才讲了半天，其实是软件漏洞，所有的计数器、限速器归根结底是软件，可以改掉。但有什么东西是没法改的？后来我们就去看。这个是去年GeekPwn的照片，这个攻击大概的原理，先了解TCP收包的原理，通常TCP收包时要看这个包是不是匹配了当前的某一个连接，如果没匹配的话这个包就直接丢了，如果匹配的话会去看你这个包的序列号，如果不对的话它会触发一个回复，说你那个序列号有问题，这个才是正确的序列号。如果序列号对了，反向序列号不对，也是会丢包的，当你做所有的检查通过时也会回一个包。大概TCP是这样的过程，我把它简化了很多。
这种情况下，如果我们再调转枪头，让非中间人攻击去伪造服务器给客户端发包，去猜是不是有这样一个连接存在的话。如果我猜错了，比如猜客户端原端口，假设我猜错端口了，没有匹配上当前的连接，是不是这个包就丢了？如果我猜对了，是不是就要去检查序列号？序列号大概率99%是错的，因为我不知道哪个是对的，所以会触发一个回复。也就是说我猜对猜错有两种情况，要么是给我回复，要么是不给我回复，按照这个TCP处理流程就是这样。
但是有回复或没回复是非中间人观察不到的，因为它是回复给服务器的，不是回复给非中间人的。那么我们怎么观察到、连接判断客户端有没有回复？这是我们关键要考虑到的问题。具体怎么做？有一种可能做，如果我假冒服务器发一个包，这个包触发了回复，CPU要多花时间去处理这个包，可能花几十微妙、几百微妙。如果没有生成回复的话就不需要花CPU的时间。如果这个机器客户端只有一个单核，我接下来再发一个包过去需要排队，这样通过时间上的差异就可以判断出来之前那个包是不是有触发回复。这个区别太小了，基本就几十微妙到几百微妙，通过网络测量都是毫秒级的，微妙差别是测不出来的，什么时候能够测出来？在无线网络里可以测出来。原因是半双工，半双工是什么意思？如果有上行流量，下行流量就走不了。无线网络上下一起走，而且同一个频段的话是会冲突的，冲突的话还得回退，所以WiFi协议全部是半双工的，如果这个出了问题的话这个漏洞是修不了的
大家可以看看这个流程是什么样，我们怎样让有回包的和没回包的时间差异放大。先看客户端跟无线路由器之间划出来，它是半双工的。作为攻击者，可以先发一个包，测一下时间。然后再发一个包，这个包可能跟上面的回复有冲突，这样我会往后发，稍微延迟一下再发，这个没关系。最后会再发一个包，第三个包测试一下我收到回复的时间，因为第二个包猜得是错误的，所以到客户端是没有收到回复的。如果客户端虚线往下走时跟第三个包往上走时冲突，冲突以后第三个包又要往后延。这个时候再去看第三个包RTT时间就变长了，所以只要判断RTT是大还是小，就能够猜到第二个包是触发了回复还是没触发回复，就这么简单，这个是不是修不了。
大家说，这个回复冲突一次就有这么大的区别吗？其实一次没有这么大，但我们可以继续放大。因为第二个包那个虚线可以不只发一个，可以发几十个，如果都发生冲突的话，你第三个包过去的时候会一直冲突，这样就能够放大到毫秒级。所以我们做了个测量，在本地实验的环境下，如果你发40个包，就有2毫秒的差别。
再看一个真实的环境，客户端跟攻击者在北京两头，他们的RTT是20毫秒的距离，我们去做这个实验，发现有回复和没回复基本可以差到5毫秒，5毫秒在20毫秒范围内，这个信号跟噪声相比已经足够好了。
这个视频是如果被攻击者、受害者访问了我们的网站，这时javascript会在后台执行，主动建立一个连接，比如到工商银行这样的网站，因为工商银行主页不加密，我们可以劫持，换它的主页，并且让它的主页在我们浏览器缓存几十年，这时按F5刷新是没有用的，只有一种方法，就是把你浏览器里面的缓存清空，否则永远都是这个错误页面。这个攻击不是操作系统或者软件的漏洞，它是物理层面的问题，基本所有操作系统和浏览器都能够做这个攻击，而且成功率还很高。但花得时间不太一样，因为我们猜序列号是从0开始猜的，如果近的话很快就能够猜出来，远的话就多花他时间。而且所有的攻击站是开源的，很多时候攻击站不愿意放出来是因为考虑到道德的问题，要补丁先打好了才公布细节，但这种情况下没必要，为什么？因为这个漏洞修不了。我们跟IEEE 802.11工作组聊过，还开了视频会议讨论这个问题怎么办，他们认真跟我们聊了很久，最后讨论的结果是他们真的无能为力，没有办法，底层改不了。
我就讲到这里，大家可以看看TCP侧信道可以有各种方法做攻击，有些漏洞还是没法修的。如果大家有什么问题，接下来可以跟我聊，我们实验室一直招收博士生。联系方式:zhiyunq@cs.ucr.edu。
声明：本文来自看雪学院，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
