VPN 和 Tor 并不取代 HTTPS：每一层在哪里结束

VPN 和 Tor 链路都只在你旅程的一部分中加密流量。两者都会在各自选定的对端停止加密。HTTPS 是唯一到达网站本身的层，前面堆多少隧道，都不会把明文表单提交变成受保护的提交。把每一层追到它真正结束的地方，这一点就一目了然。

三层，三个不同的终点

传统 VPN 在 VPN 服务器上结束隧道。设备与该服务器之间的一切都在隧道里，之后的一切则不在。Tor 链路与另一个对端同理，在出口中继处离开网络，把请求转发给目的地。

TLS 在网站处结束。你验证过的证书把主机名绑定到网站控制的密钥上，会话密钥存在于你的浏览器与那台服务器之间。这个终点在 VPN 服务器和 Tor 出口之外。

因此三层有三个不同的信任边界，一个请求会依次穿过全部三层。加固其中一层并不能说明其他层，而最后一层是目的地唯一参与的一层。

如果应用使用明文 HTTP，出口之外的内容任何运行该跳的人都能读取。先前的隧道完美完成了自己的任务，只是如今已不存在。输入 HTTP 表单的凭据，恰好在保护结束的那一点上暴露。

Layer	Terminates at	Who can read the request there
VPN tunnel	The VPN server you selected	The operator of that server, and anyone who can compel them
Tor circuit	An exit relay chosen by the network	The exit relay operator, for traffic that is not otherwise protected
HTTPS	The website's own TLS endpoint	The site itself, and no intermediary on the path

在正确验证 HTTPS 的情况下，路径上的中间人既不能读取也不能悄悄修改应用内容。它仍然看得到你何时连接到哪个地址，因为数据包首部必须可路由。内容的机密性与关于连接本身的元数据是两种不同属性，TLS 只提供前者。

账户身份又是第三件事。登录账户会让该服务知道你是谁，与你使用哪个出口地址无关，所以出口保护的是网络路径而不是账户。这一区别在它前面有任意多层时都成立。更换出口从不改变已登录会话所透露的信息。在第一个数据包发出之前，服务就已经知道你是谁。

这套安排不会因为再加一条隧道而被破坏。改变的是哪位观察者看到第一跳，而不是最后一跳是否加密。

把 VPN 与 Tor 串联起来，是在网络层面改变谁能看到什么的一种正当方式。在 VPN 上运行 Tor，会向你的接入网络隐藏你使用 Tor 这一事实；而在 Tor 上运行 VPN，会向 VPN 服务商隐藏你的地址。两种顺序都有公开文档描述，也都在性能与故障行为上有取舍。

两种顺序都不会移动 TLS 终点。两种情况下浏览器仍然会为所请求的主机名验证证书，两种情况下 HTTP 地址仍然会把内容在最后一跳之后以明文发出。组合改变的是观察者名单，而不是目的地的层数。

正因如此，关于串联的建议通常针对威胁模型，而不是泛指安全。更长的链并不是同一件事的更强版本，也不能替代应用所选择的协议。

curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief

两条命令都显示了目的地真正重要的那一层。第二条不涉及任何隧道，直接打印协商出的协议。两者都不会告诉你所用出口的任何信息。

证书警告是关于你即将建立的连接的信息。它可能意味着主机名不匹配、时钟问题、不可信的证书链，或一次拦截尝试。因为连着 VPN 就添加永久例外，会移除唯一能区分这些情况的那条信号。

Tor 浏览器的安全连接功能及其警告出于同样的理由存在，为了打开页面而关掉它们，是把可见的失败换成看不见的失败。如果某个站点不加例外就无法访问，诚实的结论是这条连接无法验证，而不是隧道让它安全了。

加密同样不代表意图。与欺骗性站点之间的有效 HTTPS 连接，会以完美的机密性把你的数据交给那个站点。要检查地址和你要提交的内容，而不只是看有没有锁形图标。

Onion 服务是真正不同的模型。它们通过 Tor 网络到达，没有普通的公共出口，这与通过 Tor 访问公共网站并不相同。把它当作一个有其自身预期的单独情形，而不是同一次访问的更强版本。

在每一种配置下都成立的原则很短。保持浏览器验证完好。以每一层真正结束的位置来评判它。