DeepCorr 的关联技术可以对所有 Tor 用户进行去匿名化吗？

不，它不能取消匿名所有Tor 用户。

（但是它大大缩小了成功去匿名化的范围）

为什么，什么是流量相关攻击

流相关攻击是一种攻击，其中攻击者在不同的网络位置拦截网络流使用数学统计或机器学习方法（例如神经网络）“关联”它们。

DeepCorr 的设置包括一个“有 M 个入口流和 N 个出口流”的网络：DeepCorr 监听入口流，在一端更靠近用户组，它只是试图找出流量开始离开电路的时刻在另一端。它的意思是“抓住了”！

网站！= 流量

越来越多的人在同一时间浏览大小相似的网站（其中许多是简单的网站），当其他流量具有相似特征时，他们如何仅使用大小和时间来判断流量来源？

DeepCorr 不进行网站指纹识别（这是另一类攻击，如文章中所述），它只是在网络的两个不同点将“流 A”与“流 B”相关联。

网站相似性对于成功的关联并不重要，DeepCorr 使用小数据包序列的特征进行操作：大小、时间、流向（输入/输出）等。

仍然...

相关性！= 去匿名化

从文章：

为了能够执行流量关联，攻击者需要观察（即拦截）进入和退出 Tor 网络的流量的一部分。然后，攻击者可以对特定的 Tor 连接进行去匿名化......

我会说“但可能不会去匿名化”......我的意思是，似乎成功的流量关联攻击并不自动意味着成功的去匿名化。相关性意味着“这些用户访问了这些网站组”（但它大大缩小了用户集并增加了去匿名化的可能性）。

Firefox 会生成其他模式吗？

这可能是它对他们如此有效的原因吗？可能是 firefox 产生了一些额外的独特流量，而 Tor 浏览器由于广告和 cookie 等原因而不会产生这些流量？

在我看来，Tor 和 Firefox 的流量没有太大区别。

示例：google.com

Firefox:
25 requests
1.31 MB / 677.67 KB transferred

Tor:
19 requests
1.39 MB / 498.30 KB transferred

直观地说，我会说两种浏览器都会生成一些独特的流模式，并且不会忘记那个网站！=流。

也似乎 DeepCorr 不需要太多的流量来衡量：

“所有系统的相关流都是 300 个数据包长”......

Tor 的隐藏服务

这种攻击也可以针对隐藏服务（版本 3）吗？

我会说“为什么不”：DeepCorr 对流量执行，它不关心流量是否“隐藏”，隐藏服务只是另一个流量。DeepCorr 将关联入口和出口，这就是它的作用。

PS：关于可能的对策的几句话。

对策

正如作者所说：

“我们的结果表明，（公共）Tor 中继应该部署像obfs4 这样 IAT=1的流量混淆机制，以抵抗像 DeepCorr 这样的高级流量相关技术。”

（IAT=0 没有帮助）

“但是，由于成本增加、开销增加（带宽和 CPU）以及此类混淆机制所带来的 QoS 降低，这并不是一个简单的解决方案……设计一个为 Tor 量身定制的混淆机制，在性能之间取得适当的平衡、成本和匿名性仍然是未来工作的一个具有挑战性的问题。”

我不认为他们的方法适用于识别用户，我将专注于流相关技术并解释为什么不可能实现它（当然我可以调整并创建一个用例并使其成为可能，但不适用于互联网）。

一般来说，现在所有的通信都使用 TLS 进行加密，tor 也是如此，HTTP 1.1。在 HTTP 1.1 中，多个请求和响应将在同一流中进行，这意味着您需要关联上游 pdus 的数量（通过检查 TCP 推送标志）和下游。例如，如果我制作了一个可以访问两个 url 并下载两个图像的 python scrypt，系统可以生成一个流特征向量，例如：

[{"upstream_bytes": 500, "downstream_bytes": 5000},
 {"upstream_bytes": 400, "downstream_bytes": 4000}]

第一个请求将在上游生成 500 字节的加密数据，并在下游接收 5000 字节的加密数据，并且随着第二个请求，400 向上和 4000 向下。

考虑到这个最小的场景以及浏览器生成不同的请求大小，可能大多数浏览器会为第一个请求 (index.html) 生成一个类似的第一个请求模式，但字节会有一些变化。

所以访问相同服务的多个用户将有一个向量

[{"upstream_bytes": (500, 600), "downstream_bytes": (5000, 5500)},
 {"upstream_bytes": (390, 420) "downstream_bytes": (4000, 4300)}]

上游和下游将根据浏览器和 TLS 加密等因素而有所不同。

因此，如果目标站点也支持php，并且其他用户组访问index.php，则向量相同的概率很高。这意味着即使您使用机器学习或其他技术也无法访问流内部的内容并使相关性更加不可能。唯一可以建立的流量关联是通过将（上游和下游的）向量与其他流量的其他向量进行比较，并通过统计数据进行比较。在您可以控制网络（用户和服务器）的测试场景中，您可能很容易猜到，因为您没有任何其他流量会为检测产生噪音。

如果您还想考虑在仅提供所有大小相同的 pdf 文档的目标服务器中，这将为使用该服务的所有用户提供相同的流量分配，使他们无法知道内容。

另一方面，如今的浏览器会为同一个站点生成多个网络流，这让这变得更加困难。

总的来说，这篇论文很好，并且有一些有趣的提示，但有很多研究论文，特别是那些检测事物、调整结果以使其发表的论文，我不是说是这样，但看起来有点怀疑结果很好，而且他们不发布数据集，因此其他研究人员可以验证或改进他们描述的技术。