TrafficSliver: Fighting Website Fingerprinting Attacks withTraffic Splitting

2020

轻量级防御 Tor

通过用户控制的多个 Tor 入口节点上的流量分割，trafficsliver限制了单个入口节点可以观察到的数据，并扭曲了WFP攻击所利用的可重复流量模式。并非插入任何延迟或虚拟流量。

trafficsliver在网络层

网络层防御的核心思想是将TCP流量分布在多个电路上，这些电路建立在几个唯一的条目上，但共享中间和出口ORs。

多路径隧道创建  为了通过多个唯一的条目 OR 传输数据，用户的 OP 创建多个单独的电路、子电路，沿着这些条目 OR 中的每一个到公共的中间 OR。每个子电路构成我们的多路径传输方案的一条路径。通过其中一个入口 OR 建立初始三跳子电路（步骤 1）。接下来，它创建 𝑚 − 1 个两跳子电路，从尚未选择的条目 OR 之一开始，并以初始三跳电路中使用的相同中间 OR 结束（步骤 2）。一旦构建了这些子电路，连接过程就会通知中间 OR 有关 𝑚 − 1 个两跳子电路和初始三跳子电路之间的关系。为此，采用基于 cookie 的身份验证机制，其操作由用户控制和验证（步骤 3）。
我们的 cookie 机制的操作受到 Tor 洋葱服务中应用的集合 cookie 的启发，用于在用户和洋葱服务之间建立连接。为了验证各个子电路之间的关系，用户首先沿着最初创建的三跳子电路将生成的cookie发送到中间OR。引入了两个新的 Tor 单元：SET_COOKIE 和 COOKIE_SET。 当用户使用 SET_COOKIE 来最初将新创建的 cookie 发送到中间 OR 时，COOKIE_SET 由中间 OR 发送以确认（成功）收到 cookie。然后，用户通过在另一个新引入的 Tor 单元 JOIN 中传输相同的 cookie，通过这些子电路到中间的 OR 来加入剩余的两跳子电路（步骤 4）。当接收到的 cookie 与已存在的三跳子电路的存储 cookie 成功匹配时，中间的 OR 会通过新的 Tor 单元 JOINED 确认加入过程，完成了连接的建立。

拆分和合并流量  使用双向电路级信元分裂来实现多路径用户连接（步骤 6）。为了执行实际的拆分，用户的 OP（或中间 OR，取决于方向）通过单独确定的子电路发送包含用户流量的每个信元。然后，各个合并点接收各个子电路上的信元，并将它们重新组装成完整的数据流，以供进一步转发或处理。重要的是，Tor 只处理只有按顺序交付的单元。引入了一种新的控制单元INFO，其中用户定期宣布传输单元的顺序及其对中间OR的子电路分配（步骤5）。如果信元的传递被延迟，则相应的合并点将缓冲所有后续信元，直到丢失的信元到达。然后，按顺序处理所有获得的单元。 除了实现正确的单元排序之外，我们还引入了拆分指令的概念。根据所选的分割方案（参见第 6 节），用户定期向中间 OR 发送 Tor 指令信元，指示它如何将向后定向的用户流量分割到子电路。 因此，中间 OR 处的流量分割由用户控制，用户仅按预期顺序接受向后定向的流量。为了确保出口 OR 处单元的正确解密（或加密，取决于方向），用户的 OP 对所有两跳子电路重复使用与出口 OR 协商的加密密钥（三跳子电路设置，步骤 1）电路。 因此，TrafficSliver-Net 仍然对三个洋葱层中的所有单元进行加密。

执行  我们在 Tor 版本 0.4.1.6 中实现了 TrafficSliver-Net。 我们的修改主要集中在电路和 Tor 单元的处理上。此外，我们引入了一个新的拆分模块，该模块维护子电路并提供生成和管理身份验证 cookie、拆分指令和拆分策略的功能。

trafficsliver在应用层

完全独立于底层匿名化网络，与 net 相反，这里不需要对 Tor 进行任何修改。作为用户浏览器和用户OP之间的本地代理。代理支持两种操作模式：（1）通过不同的入口OR为属于同一网站的不同web对象发送单独的完整HTTP请求（2）通过不同的电路请求单个web对象的不同部分。

浏览 Web 时，用户通常会发送一系列 HTTP GET 请求来获取显示站点所需的所有 Web 对象。 HTTP/1.1 协议为 GET 请求提供了一个附加功能，即范围选项，它允许下载 Web 对象的一部分（最初使用，例如，用于恢复获取大型对象）。TrafficSliver-App 利用此范围选项将每个传出 GET 请求拆分为多个部分请求，请求单个 Web 对象的不同部分。每个请求的拆分都基于预先选择的拆分策略（参见第 6 节）。然后，代理通过用户 OP 已构建的电路之一将每个新生成的部分请求传输到 Web 服务器。这里要满足的一个重要要求是确保属于单个完整 GET 请求的部分请求的多个部分不会遍历相同的电路，从而揭示可重复的流量模式。反过来，Web 服务器单独处理每个部分请求，并将 Web 对象的相应部分发送回我们的代理。最后，代理合并每个资源的所有获得的部分，并在单个 HTTP 响应中将该资源返回到用户的浏览器。

拆分和合并HTTP流量  每次用户浏览器发送一个GET请求时，首先缺点这个请求是否能分割成多个部分请求。

执行  作为HTTP代理开发的

流量拆分策略

目标拆分方案应该在同一页面的不同负载之间产生高度多样化的流量分布，从而阻碍对抗性入口OR识别模式。

用于流量分配的表项ORs个数  首先需要定义 Tor 用户用于多路径通信的不同入口ORs 的数量m 。

多电路上的流量分布  一旦选择了条目 ORs 的数量，需要定义如何通过他们分配web流量。虽然-App依赖于每个web对象的大小，但既不能直接管理单独 Tor 单元的传输，也不能直接影响传入流量的电路选择；而 -Net 不知道通过它交换的 Web 对象，但可以处理用户发送或接收的每个单元。 因此，特别旨在分配单独的 Tor 单元的分割方案不能在应用层应用，反之亦然，对 GET 请求进行操作的分割方案不能在网络层使用。