链路加密保护路径，出口节点仍能读取明文
333 个 Tor 出口节点被劫持，暴露了匿名网络最脆弱的一环。攻击者控制了出口节点，就能看到经过该节点的流量。若访问的是 HTTPS，网站内容仍受传输加密保护；若用户连接普通协议或明文服务，敏感信息就会直接暴露。
我以前理解 Tor，主要盯着浏览器地址栏和线路选择。用户流量经过多台中继，来源地址不会轻易落到目标网站。链路加密也覆盖了节点之间的传输过程。后来我才意识到，这条链路只保护数据在路上如何移动，不负责判断数据本身是否安全。
出口节点掌握最终连接。攻击者控制它以后，不需要破解层层中继，只需等待用户提交未加密的信息。登录口令、私信内容，甚至明文 SSH 凭据，都可能在这个位置被截取。
HTTPS 会保护网页内容，普通协议和明文服务却可能直接暴露敏感数据。
这正是本次事件最值得警惕的地方。攻击者想偷的是数据，便把目标放在能够读取明文的位置。规模化的节点劫持，让这种风险从个别失陷扩散到更多出口。Tor 的匿名性依赖整个网络共同维护，任何一环被控制，边界都会随之松动。
恶意出口动摇了匿名网络的信任基础
本月有 3 天发生出口节点遭入侵，说明风险已经形成现实压力。我的判断很直接：Tor 的安全不能建立在用户记得给每个服务加一层加密这个前提上。链路加密解决传输隐蔽性，应用层加密决定最终内容是否安全，两者承担的任务并不相同。
我第一次认真使用 Tor，是在网络审查突然收紧的时期。那时我把匿名理解成一个开关，连上就能把真实身份藏起来。用了几年以后，我才看清匿名依赖很多条件共同成立：客户端配置正确，节点运营者可信，目标网站没有反向识别，用户也没有在明文协议里交出秘密。
昨天，我在《Tor出口节点大规模劫持暴露匿名网络信任危机》里写过，大规模劫持出口节点说明 Tor 的匿名性依赖整个网络的共同维护。这个判断今天仍然成立。本次报道补上的细节是，攻击持续了 3 天，受影响范围涉及 333 个出口节点，目标明确指向敏感数据窃取。
我也在 10 月 29 日的《Tor出口节点大规模劫持暴露匿名网络信任危机》中讨论过出口节点的安全边界。当时我强调路径选择隐藏来源、链路加密保护传输，却无法替应用层内容加密。连续几篇写同一件事，也让我意识到一个问题：把责任反复推给用户，并不能让网络变得更安全。
出口节点一旦被控制，路径隐藏做得再好，也可能挡不住最终连接中的明文数据。
我不同意“用了 Tor 就能避免数据泄露”的简单说法。匿名和内容保密需要分别处理。只关注地址隐藏的人，可能忽略登录协议；只追求速度的人，也可能直接关闭本来存在的加密选项。安全选择必须落在具体应用里。
用户需要给数据再加一道锁
链路加密保护节点之间的数据，应用层加密保护最终内容。用户访问 HTTPS 网站时，出口节点通常看不到网页正文。但只要协议本身没有加密，链路中的层层保护就无法补上最后一道缺口。
我不会把全部责任归给用户。Tor 的设计有意减少中心化控制，让分散节点共同组成网络。代价也很清楚：网络规模越大，运营质量越难统一，恶意节点和被劫持节点带来的风险越难彻底消除。
因此，我更愿意把出口劫持视为一项系统性提醒。节点运营者需要提高防护能力，用户需要检查协议和证书，客户端也需要减少不可信出口带来的暴露。单独修补任何一端，都不能代替其余环节。
链路加密管“数据怎么走”，应用层加密管“内容写什么”，两者缺一不可。
到今天，我仍未找到一个既保持 Tor 分散结构，又不让用户承担全部安全负担的答案。333 个出口节点遭劫持，暴露了这种信任结构中的薄弱处。它至少提醒我们，匿名网络真正保护的对象从来不只是地址，还包括途中出现的数据。
如果出口节点能够看到更多未加密流量，我们究竟该继续信任分散网络，还是接受更多中心化控制？这道选择题，可能比讨论某一种协议更泄露用户的安全需求。