了解 Wehe 在 HTTPS 流量检测方面的不足

链接表

摘要与引言

相关工作和背景

TD 检测测量设置开发中的挑战

案例研究：Wehe - 移动环境的 TD 检测工具

Wehe 在 HTTPS 流量上的缺陷

TD检测HTTPS流量

结论和参考文献

五、WEHE 对 HTTPS 流量的缺陷

我们的研究重点是验证重放流量流的网络响应、TD 检测和各种网络配置中的操作可行性。虽然使用 Google Playstore 上公开提供的“Wehe”Android 应用程序验证了操作可行性，但使用理论论据验证了 TD 检测场景。网络响应的验证需要对接收的流量流进行带宽分析。此分析需要根据验证场景执行的特定重放的网络日志。在设备上进行的重放和多个其他流

图 6. 重放 YouTube 流量的流量分类

并行运行的服务就是这样一种场景。Wehe 应用程序不会在测试完成后立即提供此类网络日志以供重播。因此，我们实现了模仿 Wehe 工具行为的用户客户端和服务器。

我们使用类似于图 3 所示设置的客户端-服务器设置来验证 Wehe。在当前设置中，我们用重放服务器替换了原始服务的服务器。用户客户端和重放服务器通过商业流量整形器连接。此外，我们的设置可以并行执行多个重放。我们的验证设置不需要管理通道和开销，例如侧通道。我们的服务器始终需要支持单用户客户端。由于不需要相关的流量分析，因此对具有多个客户端的场景的验证直接使用 Wehe App。

本节的提醒描述了验证的结果。

A. 原始服务的流量模拟

网络响应取决于网络策略的应用，该策略基于网络中间盒对流量进行正确的探测分类，如第 III-A 节所述。我们使用商业流量整形器验证了 Wehe 模拟流量的分类。使用商业流量整形器的用户界面可以观察模拟流量的分类。

为了进行实验，YouTube 应用程序数据通过商业流量整形器从重放服务器重放至用户客户端。在数据传输过程中，观察商业流量整形器的用户界面窗口是否存在 YouTube 流量。我们还使用互联网浏览器访问 YouTube 流量，并观察流量整形器的分类结果，以作为我们流量分类观察的基准。

图 6 显示了商业流量整形器用户界面窗口显示的流量分类结果，该窗口针对使用互联网浏览器直接从 YouTube 服务器访问的流量。它在左侧窗口中显示互联网活动，在右侧窗口中显示相应流量的分类。

图 6(a) 显示，使用互联网浏览器访问的流量被正确分类为 YouTube。这符合商业流量塑造者的预期行为。

图 6(b) 显示了使用用户客户端访问的流量的流量分类结果。它显示了没有通过通信链路传输 YouTube 流量的证据。此外，它将相同的流量分类为 HTTPS 流量。该实验的结果表明，并非所有网络中间件都能正确分类 Wehe 的重放流量。

B. 重放脚本中数据速率的影响

探测流量生成会影响网络响应，正如 TD 检测算法所预期的那样。Wehe 使用来自原始服务的流量跟踪来生成重放脚本，以保留应用程序数据及其时间关系。此重放脚本用于原始网络以及地理位置不同的网络。由于同一服务的流量整形速率在不同网络上有所不同（如 [32] 中所述），因此重放脚本中保存的流量速率可能与当前考虑的网络的流量整形速率不同。重放流量速率可能低于流量整形速率。

如果重放脚本的流量速率低于网络的整形速率，Wehe 方法就不会检测流量差异，因为它不会影响流量流。此类重放脚本永远无法检测此类网络上的流量整形。因此，Wehe 工具的 TD 检测能力受到重放脚本探测流量速率的限制。

C. 端口号80的使用

网络响应由网络中间盒对探测流量的感知驱动（参见第 III-A 节）。重放脚本保留应用程序原始网络跟踪中的数据。原始应用程序服务器使用端口 80 传输纯文本数据，使用端口 443 传输加密数据。Wehe 重放脚本直接使用应用程序网络跟踪中的加密数据，并在端口 80 上传输。在这种情况下，Wehe 希望其原始重放流量流能够被使用加密应用程序数据的网络设备正确分类。端口 80 上的此类数据不可能作为加密流量数据，无法将其身份暴露给网络设备。因此，由于重放运行默认使用端口 80，因此 Wehe 工具无法为在端口号 443 上运行的服务生成所需的流量流。

D. 流量负载控制网络行为

请注意，资源稀缺促使网络应用某些网络流量管理，特别是在网络负载重的情况下，这对其网络上的所有活动服务都有好处，例如基于 QoS 的流量管理（参见第 III-A 节）。我们验证了这种流量管理的效果

图7 网络负载对渭河交通流性能的影响

控制重放和原始重放的表现。验证使用以下三种场景进行验证，

• 仅重放 Wehe 的两个流量流，不对网络造成任何负载（图 7(a)）

• 使用一个附加流服务并行重放 Wehe 的三个流量流（图 7(b)）

• 使用另外 2 个并行运行的流服务重播 Wehe 的三个流量流（图 7(c)）

图 7(a) 中的性能表明，在没有额外网络负载的情况下，Wehe 工具生成的流量流的性能相同。随着网络负载的增加，控制重放的性能在更高水平上偏离原始重放的性能（图 7(b)）。虽然控制重放的性能在较低水平上进一步偏离原始重放，但两个原始重放仍然表现出相似的性能，如图 7(c) 所示。它使 Wehe 工具对控制重放没有差异的期望失效。它也使该工具因总带宽而检测 TD 的说法失效。

E. Wehe 从同一子网内的多个设备进行测试

Wehe 设计中引入了侧信道，以同时支持多个用户客户端。侧信道还有助于识别用户客户端与 IP 地址和端口组合之间的映射。在使用 NAT 的网络中，它很有用 [33]。我们使用两个不同的测试验证了 Wehe 对多个客户端和启用 NAT 的网络的支持。首先，我们连接了同一子网内的两个用户客户端，即共享同一公共 IP 地址的客户端。在一项测试中，Wehe 工具在两台设备上测试同一项服务，例如，两台设备上的 Wehe App 都在测试 YouTube。结果显示，Wehe 测试仅在一台设备上完成，而 Wehe App 在另一台设备上突然关闭。我们重复了同样的场景，但这次 Wehe 测试了不同的服务，例如，一台设备上的 Wehe 测试 YouTube，而另一台设备上的 Wehe 测试 Netflix。我们发现，一台设备上的 Wehe 测试可以正常完成，而另一台设备上的 Wehe 测试则会在屏幕上抛出错误，通知用户另一个客户端已在执行测试，如图 9 所示。这些测试表明，如果多个设备共享相同的 IP 地址，Wehe 则不支持它们。虽然侧信道对于识别直接连接到 Wehe 重放服务器的用户客户端的每个重放很有用，但在使用 NAT 设备的网络中它毫无用处。在 NAT 的情况下，多个用户共享相同的 IP 地址。在这种情况下，侧信道无法将每次重放运行唯一地映射到客户端。它将 Wehe 的使用限制为每个重放服务器、ISP 和应用程序只有一个活动客户端。Wehe 开发人员也记录了这一限制。

F. 设备网络负载对TD检测的影响

Wehe 的重放服务器使用与原始应用程序流量相同的应用程序数据传输时间。这种传输策略预计不会耗尽可用带宽。因此，由于流量速率超过可用带宽而导致源速率调制的影响不太可能发生。除非网络策略（即 TD）有意修改，否则原始和控制重放会显示类似的流量性能。

然而，这种期望并不总是能够得到满足，因为在执行 Wehe 测试时，流量数据速率会受到用户设备上的网络负载的调制。这种扰动会产生差异，因为随时间变化的当前网络负载对探测流量的影响也是随时间变化的，并且可能并不总是相同的。Wehe 的背靠背重放策略确保两个（原始和控制重放）探测流量流都会受到当前网络负载的不同影响。在设备端的这种网络负载下，服务不会耗尽可用带宽的概念以及其对 TD 检测的好处不复存在。在 TD 检测之前，有必要将这些混杂因素标准化（参见第 III-B 节）。