出口被控会直接暴露明文流量
大规模劫持出口节点，说明 Tor 的匿名性依赖整个网络的共同维护。攻击者控制出口后，可以观察流量，甚至窃取未加密的 SSH 凭据。
本月有 3 天，333 个 Tor 出口节点遭到入侵。攻击者的目标很直接，就是从出口端截取敏感数据。
Tor 的链路加密能保护传输过程，却不能替应用层加密内容。访问 HTTPS 网站时，出口拿到的是密文。SSH 连接若未额外加密，账号、密码和传输内容就可能直接暴露。
我第一次认真使用 Tor，是在网络审查突然收紧的时期。那时我把匿名理解成一个开关，连上就能把真实身份藏起来。用了几年后，我才看见这套机制最脆弱的位置。
出口节点属于路径末端。它替用户连接目标网站，天然能看到未加密的数据。攻击者控制一批节点后，Tor 用户只要恰好经过其中之一，防护就可能失效。
333 个出口被控，受影响的不只是这些节点上的用户。
规模本身已经值得警惕。攻击者如果能持续运行恶意出口，就能观察大量连接，并尝试针对登录凭据和内部工具下手。
333 个出口节点被控，意味着风险来自 Tor 路径中一个很具体的环节。Tor 没有替用户承担端到端加密的责任。
Tor 的信任模型没有承诺隐藏所有内容
Tor 擅长隐藏来源地址，也擅长绕开中心化审查。它无法保证出口节点善意运行，更无法阻止出口查看应用层明文。
这也是我写完 2026 年 10 月 29 日的《Tor出口节点大规模劫持暴露匿名网络信任危机》后，仍想继续追下去的原因。那篇文章已经指出，出口节点会直接看到未加密访问内容。这次的新信息把问题推得更远：风险已经进入真实攻击。
Tor 的多跳机制会降低单一节点同时掌握身份与目标的机会。用户还需要防范恶意出口检查会话，尤其是登录后台、远程终端和内部管理服务。
我最初以为，加密链路足以解决大部分风险。看到明文 SSH 泄露后，这个判断需要修正。链路加密保护的是路径，参与路径的节点仍可能控制末端连接。
应用层缺少加密，比“是否经过 Tor”更接近泄露发生的直接原因。用户使用 Tor，只能减少部分暴露面，不能替代 SSH、HTTPS 和具体应用的加密措施。
我不同意把“用了 Tor”当作安全证明。浏览器启用 HTTPS，终端启用 SSH 加密，管理后台启用双因素认证，这些措施都有明确边界。Tor 只是路径选择和流量转发的一层。
明文 SSH 一旦经过恶意出口，账号凭据就可能被直接截取。
信任模型的关键在于责任分配。Tor 提供匿名连接，应用开发者负责保护数据内容，系统管理员负责限制高风险服务暴露给陌生客户端。
加固应该落在应用和开发流程里
开发者应默认把出口节点视为不可信中转。敏感连接必须启用应用层加密，不能依赖 Tor 链路保护内容。
SSH 应优先使用密钥认证，并关闭密码登录。私钥还应设置本机 passphrase。远程管理工具则应增加访问控制，避免把敏感端口直接暴露给公共网络。
应用层也要限制登录失败次数，清理日志中的令牌和凭据，并对管理接口启用多因素认证。这些措施不能阻止恶意出口观察连接，却能减少凭据被窃取后的损失。
一条旧隧道、一个过期令牌，都可能扩大劫持造成的实际影响。
流量入口检测也有价值，但位置比很多人想的更靠前。检测器放在入口更有效。等数据抵达出口，已经没有足够上下文判断连接是否可信。
Tor 社区、浏览器开发者和应用开发者承担的责任不同。社区负责维护节点和目录质量，浏览器负责处理网站协议与指纹，应用开发者负责加密敏感内容。系统管理员负责管理自己的服务器。
我到现在也没搞明白，公开网络中有多少恶意节点会主动保护自己。Tor 的匿名性需要规模，规模化又会吸引攻击者。这对矛盾不会因为几条配置建议消失。
真正需要改变的是开发习惯。把明文 SSH 视为高风险操作，把每个出口都当作不可信环境。安全不应建立在匿名网络的参与者都足够善良这个假设上。