33个版本 (19个重大变更)
0.21.0 | 2024年8月1日 |
---|---|
0.20.0 | 2024年6月27日 |
0.19.0 | 2024年6月5日 |
0.14.1 | 2024年3月4日 |
0.0.2 | 2021年11月30日 |
#176 in 网络编程
每月3,587次下载
用于 22 个Crate(6个直接使用)
3.5MB
57K SLoC
tor-guardmgr
为Tor网络客户端选择守卫节点。
概述
该Crate是Arti项目的一部分,该项目旨在用Rust实现Tor。
"守卫节点"是Tor客户端用来限制敌对中继影响的机制。大致来说:每个客户端会选择一小组中继作为其"守卫"。之后,当客户端在网络中选择路径时,而不是为每条路径随机选择不同的第一个跳点,它将选择最佳的"守卫"作为第一个跳点。
此Crate提供了GuardMgr
,一个管理一组守卫节点并帮助tor-circmgr
crate了解何时使用它们的对象。
守卫节点可以在多个进程调用之间持久化。
更多的Arti用户不需要直接使用此Crate。
动机
这有什么意义?通过将它们的第一个跳点限制在很小的一组中,客户端增加了对抗流量相关性攻击的机会。由于我们假设控制电路两端的一个对手可以关联其流量,因此选择具有随机入口点的多个电路最终会导致客户端最终选择一个攻击者控制的电路,其概率随着时间的推移接近1。然而,如果入口节点限制在一个小集中,那么客户端就有可能永远不会选择一个攻击者控制的电路。
(实际的论点在这里稍微复杂一些,并且依赖于这样的假设:由于攻击者知道统计数据,暴露任何你的流量几乎和暴露所有你的流量一样糟糕。)
复杂性
由于各种因素的影响,选择和使用守卫的实际算法可能会变得更加复杂。
-
实际上,我们不可能只是“随机选择几个守卫”并永久使用它们:中继可以出现和消失,中继可以离线并重新上线,等等。更重要的是,长时间保持守卫可能会使针对这些守卫的针对性攻击更具吸引力。
-
此外,我们可能对连接的位置有限制。例如,我们可能只能连接到80和443端口,但仅限于在通勤列车的Wi-Fi网络上。
-
我们需要抵抗来自只允许一小部分守卫中继的本地网络的攻击,迫使我们必须选择这些中继。
-
在优先使用守卫的情况下,我们需要提供良好、可靠的性能。
这些需求使得我们的API变得稍微复杂。我们不仅要从GuardMgr
请求守卫,电路管理代码还需要能够通知GuardMgr
某个守卫已失败(或成功),并且将来可能需要不同的守卫(或不需要)。
此外,GuardMgr
代码需要能够分发临时守卫,实际上是在说“你可以尝试使用这个守卫来建立电路,但请在我告诉你安全之前不要实际使用这个电路。”
有关确切算法的详细信息,请参阅guard-spec.txt
(以下链接)以及此包中的注释和内部文档。
局限性
- 我们的电路阻塞算法是从Tor使用的算法简化的。有关更多信息,请参阅
GuardSet::circ_usability_status
中的注释。另请参阅提案337。
参考文献
守卫节点最初由Matthew Wright、Micah Adler、Brian N. Levine和Clay Shields在2003年IEEE安全与隐私研讨会论文“Defending Anonymous Communications Against Passive Logging Attacks”中提出(作为“辅助节点”)。(见https://www.freehaven.net/anonbib/#wright03)
当前Tor的守卫选择算法在Tor的守卫规范文档中描述。
编译时功能
-
bridge-client
:构建支持桥接功能。桥接是未列在Tor网络目录中的中继,可用于反审查目的。 -
pt-client
:构建支持可使用插件传输接触的守卫。插件传输是联系Tor中继的替代机制,用于避免审查。 -
full
:启用上述所有功能。
许可证:MIT OR Apache-2.0
依赖关系
~23–37MB
~567K SLoC