VPN 中的 DES 与 3DES：为什么两者都是错误的升级

两种密码都已过时，而且都不是新流量的正确目标。有用的比较不是 DES 对 3DES，而是已退役的算法对仍在维护的算法。如果网关仍提供其中任何一种，工作就是找出是什么在要求它并移除这项要求，而不是在两个死胡同里挑更强的一个。

人们仍在搜索的那种比较是错的

2000 年代写下的回答把 DES 与三重 DES 相比较，并得出结论说三重 DES 更强。那在当时是合理的，如今却毫无用处，因为两者都已退役，不再用于保护新流量，而它们之间的选择不过是两个死胡同之间的选择。

NIST 于 2005 年撤销了 DES 标准，其 TDEA 建议也于 2024 年初被撤销，因为将 TDEA 用于新的密码保护的截止期限在 2023 年底已经过去。这些日期描述的是一次迁移，而不是一种排名。短会话或低价值消息并不能重新打开这个问题，因为算法的状态并不取决于密钥使用多久。

密钥更新是一项独立的控制，它并不能恢复批准状态。

把协商与数据路径分开

VPN 协议在不止一处协商保护。控制通道可能使用一套算法，而被承载的数据使用另一套，并且提案列表只说明对端愿意接受什么。要读取协商后的结果，而不是提案。这一区别解释了一种常见混淆：网关仍然列出一个旧算法，运维人员便以为它正在被使用，实际上它可能只是被提供而从未被选中，或只为一个旧对端而被选中。

在 IPsec 网关上，相关的输出是安全关联；在 OpenVPN 上，则是连接日志中的密码与 TLS 设置。两者都说明了实际选择了什么。仅仅因为配置文件里还留着一个旧选项，并不能证明其中任何一个。

如果看不到协商后的结果，就不能声称该密码已被退役。

找出仍在要求它的组件

遗留要求来自三个地方：一个提供不了更好算法的旧客户端、一项仍然列出该算法的网关策略，以及一台只会说旧协议的设备。每一种的解决办法都不同。在启用兼容性提供方之前，先问清约束的归属方是哪一种，因为一旦启用，它会影响每一个连接的对端。

对于单台暂时无法替换的设备，把一台仍在维护的网关放在它前面，并限制那道边界所承载的内容。这样就把旧密码关在了里面，而不必让每个远程用户都继承它。

隔离并不是补丁，也不会让遗留主机变得可信。

用你已有的检查来完成迁移

当预期的对端以仍在维护的配置连接成功、协商出的算法套件与预期一致、应用正常工作，迁移才算完成。全程保留服务器身份验证与账户检查；更换密码并不是放松这些的理由。

openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'

把客户端与网关版本记录在协商结果旁边，这样下一次审查就能看出实际改变了什么。

通过其归属方撤销旧的许可，然后确认只提供已退役算法的对端现在会被拒绝。留下旧选项仍然启用的迁移，等于没有发生。把拒绝的证据与变更记录放在一起，因为下一次审计会问你凭什么知道，而删掉一行配置比记录在案的拒绝要弱得多。趁会话还新鲜，把测试日期与对端身份补进那份记录。

历史数据是另一个问题

读取多年前受保护的存档，可能确实需要旧算法。那是对既有材料的解密，与保护新流量并不是同一件事。

把这类工作放在隔离主机上，写明用途，并附上一份谁可以执行的简短名单。

这一区别很重要，因为它是让已退役密码保持可用的唯一诚实理由。它为范围受限的工具提供了正当性，却从来不能为公共 VPN 配置里的一行永久条目提供正当性。