- Authors: Kevin Bock, George Hughey, Louis-Henri Merinno et. al.
- conference: SIGCOMM 2020
这篇文章主要讲着这么一件事情，大部分的对抗审查的方案都需要在客户端做文章，但是这也会有一些问题：比如客户端运行一个代理程序可能不安全、代理程序不够通用、大部分用户对于审查是无感知的 …
那么可不可以只在服务器一端通过对 TCP 报文的修改整合来实现绕过审查呢？ 文章利用 Geneva 这样一个基于遗传算法的流量分析工具来寻找只在服务端对流量进行修改来绕过审查的方案并且发现了一系列这样的绕过的方案。文章说自己的主要贡献是发现了有服务端发起绕过也是可以的。
根据文章的模型，大部分的审查都是 Man on the middle，也就是审查者可以观察和分析通信双方的所有流量，同时可以在连接中插入 RST 等报文来干扰连接。更加强的攻击是 Man in the middle, 也就是审查者直接位于通信链路的中间位置，可以直接阻断连接双方（通常有巨大的延迟影响？）。在 MotM 的情况下，就有很多客户端可以绕过手段了。
在不同的上层应用和不同的审查机制下，这些绕过方案可能会有一些不同。举个客户端绕过的例子，比如通过客户端和服务器发起一个 TCP 连接的头两个报文是 SYN 和 ACK+SYN 报文。此时，客户端构造一个精心设计的 RST 报文。这个报文的 TTL 只能到达审查处而无法到达服务器端。这样，审查认为这个链接被终止了，但是实际上服务器并没有收到 RST 报文。这样就建立了连接。再举一个服务器发起绕过的方案：服务器在收到客户端发起的 SYN 报文后，分别单独地发送 ACK 报文和 SYN 报文。由审查过滤 ACK 报文后， SYN 报文继续和客户端重新建立三次握手。
文章进行了大量的实验。他们针对不同的防火墙（四个国家）以及不同应用（DNS over TCP、HTTP、HTTPS、FTP）等场景下，企图使用 Geneva 来寻找绕过的方案，并最终给出了绕过的方法。文章还对结果进行了分析，给出了兼容性测试以及对审查防火墙本身进行了一些讨论。
（作者补充：这个团队的博客上分析了近期对于 ESNI 的封锁，同时也给出了针对 ESNI 封锁的绕过办法。）
本人保留对侵权者及其全家发动因果律武器的权利
版权提醒
如无特殊申明，本站所有文章均是本人原创。转载请务必附上原文链接：https://www.elliot98.top/post/lab/sigcomm20-come-as-you-are/。
如有其它需要，请邮件联系！版权所有，违者必究！