daniel.haxx.se

cURL and libcurl

Leeks and leaks

May 16, 2025 Daniel Stenberg Leave a comment

关于完全不可能阻止 Tor 的 .onion TLD 以避免泄漏，但同时又不阻止它以使用户能够做他们想做的事情的情况。

dot-onion 泄漏

.onion TLD 是一个 Tor 特定的域名，对于 Tor 之外的世界来说意义不大。如果您尝试使用 正常的 解析器解析其中的一个域名，您将被告知该域名不存在。

如果您向您的 ISP 的解析器询问这样的主机名，您也会向相当一部分互联网宣传您与该域名通信的意图。 DNS 本质上是不安全的，并且习惯于几乎广播给许多不同的参与者。 此 IP 地址上的用户打算与此 .onion 站点交互。

因此，对于 Tor 用户来说，永远不要使用 正常的 DNS 系统来解析 .onion 名称是至关重要的。

补救措施：拒绝它们

为了帮助防止上述 DNS 泄漏，Tor 人员与 IETF 进行了合作，最终合作以 RFC 7686 的发布而告终：The “.onion” Special-Use Domain Name。 发布于 2015 年。

该文档详细说明了库和软件应如何处理此特殊域。 它基本上说，软件在很大程度上应该 拒绝 解析此类主机名。

curl

在 2015 年 11 月，我们得知 了 onion RFC，以及它如何说明我们应该过滤这些域。 当时似乎没有人热衷于解决这个问题，并且该问题被添加到了 已知错误文档 中。

八年后，该问题仍然存在于该文档中，而 curl 仍然没有对此采取任何措施，这时 Matt Jolly 从阴影中出现并带来了 一个 PR，最终实现了 RFC 要求的过滤。 于 2023 年 3 月 30 日合并到 curl 中。于 2023 年 5 月 17 日发布的 curl 8.1.0 版本中发布。 两年前。

自该版本发布以来，curl 用户不会意外泄漏他们对 .onion 的使用。

使用 Tor 的 curl 用户 显然 会使用 SOCKS 代理来访问 Tor 网络，就像他们一直以来做的那样，然后 curl 会让 Tor 服务器进行名称解析，因为它是知道 Tor 和 dot onion 域等的实体。

这就是使用这样的代理的好处。 像 curl 这样的网络客户端可以将完整的主机名传递给代理服务器，并让它完成解析魔法，而不是由客户端完成。 这样可以避免将名称泄漏到本地名称解析器。

争议

在 curl 开始支持 Tor 自己推动的 RFC 后不久，具有 创造性 网络设置的 Tor 用户意识到并提出了意见。

有人 提出了一项建议，基于环境变量为那些设置了普通名称解析器并且已知可以的用户提供过滤器的覆盖。 环境变量构成了糟糕的 API，并且讨论没有以任何特定解决方案达成共识，因此该建议没有进入代码。

此后，当用户遇到一些问题时，此问题又出现了几次，但没有合并任何修复或解决方案。 curl 仍然阻止该域。 通常，人们会意识到，当正确使用 SOCKS 代理时，域名会按预期工作，然后讨论就结束了。

oniux

本周，Tor 项目宣布了他们的新产品：oniux：一个命令行实用程序，它使用 Linux 命名空间为第三方应用程序提供 Tor 网络隔离。

在他们介绍此新工具的介绍性网页上，他们甚至使用 curl 命令行来展示它：

$ oniux curl http://2gzyxa5ihm7wid.onion/index.html

（我决定在这里缩短主机名以进行说明。）

等一下，那个 URL 中不是一个 .onion 主机名吗？ 那么自从两年前的那个版本以来，curl 对 .onion 主机名做了什么？

正确：该示例命令行仅适用于我们实施对 RFC 7686 的支持之前的旧 curl 版本。 在我们尝试在 curl 中做 Tor 间接建议我们做的事情之前。 所以现在，当我们尝试做正确的事情时，curl 无法与 Tor 自己启动的这个新工具一起工作！

至少我们不能说我们的生活很沉闷。

嘿，这行不通！

真的吗？ 请告诉我们。 当然，立即 提交了一个针对 curl 的问题，这是完全正确的。 该工具显然是为此类用例而设计的。

那么我们如何解决这个问题呢？