Tim Hudson，OpenSSL Corporation 总裁 – 访谈系列

Tim Hudson 是 SSLeay 的共同作者，也是 2026 年 10 月 13-15 日在布拉格举办的 OpenSSL Conference 的组织者之一。他在系统和网络安全领域拥有超过 30 年的经验，现任 OpenSSL Corporation 总裁兼 Cryptsoft Pty Ltd 首席技术官。自 1995 年起，他的工作包括与 Eric Young 共同创立了后来成为 OpenSSL Library 的密码库 SSLeay，创办 RSA Security Australia 开发中心，推动美国加密出口法规的变更，领导超过 30 项 FIPS 140 验证，担任 OASIS KMIP 与 SAM 技术委员会的共同主席，并在包括 RSA Conference、AusCERT、ICMC、LinuxConf 和 OpenSSL Conference 在内的顶级安全会议上演讲。

OpenSSL 是一个全球协作的开源项目，负责开发和维护 OpenSSL Library，这是全球使用最广泛的密码库之一。它被广泛应用于操作系统、云平台、企业软件和联网设备，每天帮助保护数十亿次安全的在线交互。通过 OpenSSL Foundation 和 OpenSSL Corporation，项目致力于推动可信密码学，支持可持续的开源开发，并加强互联网的安全性。

您在 1995 年与 Eric Young 共同创立了 SSLeay，因认识到需要一种非美国的 SSL 实现，而这项工作最终成为 OpenSSL 的基础。您当初想要解决的是什么问题？当时您是否预料到这项技术会成为保障互联网安全的根本组成部分？

这个问题完全是具体的，且首先是商业问题。我当时在布里斯班的 Mincom 工作，客户需要对通信进行安全保护。当时没有可购买的方案。美国的加密出口管制导致美国产品要么根本无法提供给我们，要么只能使用极其受限的密钥长度，部署它们几乎是不诚信的。这并不是对出口政策的哲学性反对，而是一个工程问题——我需要的组件根本不存在于任何可购买的形式，而我的客户正等着我们提供解决方案。

我所拥有的是大多数人已经忘记的知识。Eric Young 几年前编写了一个 DES 实现：代码质量高、干净、自由可用，完全是出于兴趣而写，与当时的需求毫不相关。Eric 当时并未从事 SSL 工作，也并不知道 SSL。当 Netscape 发布规范时，我阅读了它，带着问题找到了 Eric，并将其描述为在他已有的基础上进行的一个相对 modest 的步骤。

这并不是全部情况。每个部分看似简单，但整体却相当庞大。一个 DES 实现只能提供一种对称密码算法，而 SSL 需要公钥密码学、任意精度算术、ASN.1、X.509 证书处理以及协议状态机，并且所有这些都必须完全正确，因为在密码学中，几乎正确和被破坏是同一件事。我最初乐观地描述了其规模。Eric 很快算清了实际需要的工作量，并且乐在其中，因为规模本身成为了吸引力而非障碍。我不确定如果没有这种规模感，项目是否会启动。

他负责了密码学核心，这也是库名中带有他首字母的原因。我则负责将库转化为其他人可以实际部署的部分：应用集成、测试、文档以及社区工作。我还主动寻找任何使用竞争加密库的场景并进行替换或转化。SSLtelnet、SSLftp、NCSA httpd 以及许多其他软件都是我的工作成果，这些都是基于 Eric 实现的密码算法和协议之上的应用。这种分工让我们各自专注于自己感兴趣的领域，我认为这正是项目能够持续下去的主要原因。

身处澳大利亚使得我们能够实现这一切，随后发现大量其他人也因为同样的原因面临相同的问题。一个为布里斯班特定客户需求而构建的系统，最终对美国以外的所有人都有用，甚至对美国内部的许多人也同样有价值。

我们当时知道它会发展成什么吗？没有。没有人一开始就打算构建关键基础设施。关键基础设施是多年以后才发现自己已经构建了的东西，当你看到有多少人依赖它时才会意识到。我们当时的目标只是解决眼前的问题，并回答其他遇到同样障碍的人的提问。回答问题的部分与代码本身同样重要。

您在密码学和互联网安全领域工作了三十余年。在此期间，威胁形势发生了哪些最为剧烈的变化？尽管技术取得了巨大进步，哪些安全问题仍出人意料地保持相似？

最大的变化是攻击系统已经成为一种有经济模型的职业。上世纪九十年代中期，入侵系统的人大多是出于兴趣。如今，这已经形成了一个产业，拥有专业化、工具链、供应链、客户支持，甚至在某些情况下还有国家资助。这改变了我们必须思考的方式，因为我们不再防御好奇心，而是防御拥有预算、期限和商业案例的攻击者。

第二个变化是规模和依赖性。1995 年的平均应用是自己编写的代码。如今的平均应用是由多个组件拼装而成，其中大部分代码出自我们从未见过、也无法点名的开发者。攻击面从你的代码转移到你的依赖上，而大多数组织并未相应调整思考方式。

始终如一的是失效模式。我们仍然在解析不可信输入的代码中写出漏洞。我们仍然发布默认设置从未重新审视的系统。证书仍然会在周六过期。凭证仍然会出现在不该出现的地方。密码学几乎从未在数学上被破解，而是被绕过、配置错误或根本未启用。如果你给我一份 1996 年十大泄露根本原因的列表和最近一个月的列表，你几乎分辨不出差别。技术已经彻底变革，错误却没有。

OpenSSL 4.0 于 2026 年 4 月发布，标志着该项目数年来的首次重大版本。此版本向我们揭示了密码基础设施的未来走向吗？您认为哪些变化最终对依赖 OpenSSL 的组织最为重要？

理解 4.0 最有价值的一点是，它主要是一次删减式发布，而这正是其意义所在。

我们彻底移除了 ENGINE 接口。删除了 SSLv3 和 SSLv2 的 ClientHello。编译时禁用了已废弃的椭圆曲线和显式 EC 曲线。将 ASN1_STRING 设为不透明，并收紧了大量 API 签名。这些改变会为开发者带来工作量，也正是关键的改变，因为一个只会不断累加功能的密码库无法保持安全。每保留一条已废弃的代码路径，就相当于为他人维护的攻击面，且无人对其进行测试。

也有新增功能：加密客户端问候（Encrypted Client Hello，ECH）、RFC 8998 支持（包括混合 SM2/ML‑KEM 组）、cSHAKE、SNMP 和 SRTP KDF、为 TLS 1.2 谈判的 FFDHE。尤其是 ECH 填补了真实的隐私缺口，因为自 TLS 1.3 推出后，服务器名称指示（SNI）一直泄露用户访问的每个站点的身份。但删减才是核心。

我最想让组织记住的要点是：4.0 并非长期支持（LTS）版本。它的支持期限至 2027 年 5 月。当前的长期稳定版本是 3.5，支持至 2030 年 4 月，并且已经包含了后量子算法。如果你想使用最新代码，选择 4.0；如果你想要一个可以制定五年迁移计划的稳定目标，选择 3.5。仅凭版本号更高而选择更高版本是我们每个周期都看到的错误。

后量子密码学已从研究问题转向迁移挑战，OpenSSL 已支持 ML‑KEM、ML‑DSA、SLH‑DSA 以及混合后量子密钥交换。对于认为量子计算仍然遥不可及而无需担忧的业务领袖，他们今天忽视了哪些风险？

最常见的错误是把它当作“何时会出现具备密码学意义的量子计算机”的问题。那并不是关键变量。正确的问题是你的数据需要保密多久，以及迁移需要多长时间。用后者减去前者即可得到实际的截止日期，而对许多组织而言，这个截止日期已经过去。

加密流量今天就可以被捕获并无限期存储。如果其中的信息具有二十年敏感性（患者记录、人员档案、知识产权、外交材料、金融状况），攻击者现在并不需要量子计算机。他们只需在未来拥有一台量子计算机，并在此期间拥有廉价的存储。这不是猜想性的攻击，而是一次实际的风险决策。

第二个被忽视的事实是迁移并非单一项目。密钥交换是相对容易的部分，而且已经在进行中：OpenSSL 3.5 将混合后量子密钥交换设为 TLS 默认，因此大量组织已经在使用后量子密钥协商，却尚未就此作出决策。签名和证书体系才是难点，因为它们涉及证书颁发机构、硬件根信任、固件签名密钥、硬件安全模块以及设计时假设 RSA 能永久使用的、寿命达十五年的设备。

第三个问题是没有人为其预算：后量子签名体积庞大。ML‑DSA‑65 的签名约是 ECDSA P‑256 签名的五十倍，SLH‑DSA 更大。这会导致握手尺寸、受限设备、字段长度硬编码的协议、卫星和物联网链路等问题。只有通过实际测试才能发现这些问题，而不是单纯阅读标准。

后量子迁移的挑战之一是组织可能根本不知道其应用、基础设施、设备和第三方依赖中到底使用了哪些密码技术。公司应如何进行密码资产清点和密码敏捷性建设，以避免下一次重大算法迁移成为紧急情况？

首先要面对一个不舒服的事实：你不能仅通过向供应商发送问卷就建立密码资产清单。你会得到营销文案、诚实的未知以及三次发布前的答案。我之所以这么说，是因为我最近花了大量时间阅读硬件供应商在相关领域的文档，而文档声称与实际产品功能之间的差距远超大多数买家的预期。

你必须主动调查。共分三层，需要不同的技术手段。你写的代码：静态分析、依赖扫描、以及搜索多年以前硬编码的算法标识符。你链接的代码：软件材料清单（SBOM），扩展为密码材料清单（CBOM），这正是 CBOM 工作真正有价值的地方。你购买或连接的东西：网络观察，因为系统在网络上实际协商的内容才是事实，且常常与大家的预期不符。

关于敏捷性，原则很简单，实践却不易：算法应当是配置决定，而不是代码修改。如果更换密码需要开发者、构建、测试周期和发布，那么你没有敏捷性，而是一个项目。将密码操作集中在你可控制的接口后面，这样只需在一个地方更改，而不是四百处。

随后是几乎所有人都会跳过的环节：实际演练。未使用过的敏捷性只是一种声明，而非能力。挑一个安静的周末，在非生产环境关闭某个算法，观察会有什么破坏。一定会有。比起在强制的紧急迁移中才发现问题，提前在自己的时间表上发现要好得多。

一个有用的强制因素是证书生命周期。业界正向显著更短的证书有效期转变，这使得手动管理证书变得不可行，并迫使自动化成为必需。如果你能够正确地自动化证书的签发和轮换，那么你已经构建了未来算法迁移所需的大部分机制。

AI 正在改变网络安全防御以及攻击者的能力。您认为 AI 真正改变了安全格局的哪些方面？而组织在技术上投入过多、却忽视更根本的弱点的地方又在哪里？

AI 真正改变了一件事，我可以直接说明，因为我们亲身经历了。

今年在 OpenSSL 中披露的大量漏洞都是通过 AI 驱动的分析发现的。1 月我们发布了一个修复十二个问题的版本，几乎全部来自一个使用自动化分析的研究团队，并且他们在提交报告的同时提供了补丁。6 月我们修复了一个在 PKCS#7 验证中被 AI 系统协助的研究人员发现的高危使用后释放漏洞。这在发现成熟 C 代码中内存安全和解析错误方面是一次真正的能力提升，该代码已被专家审查多年。我在其他密码库中也看到相同的模式。分析今年的 Bouncy Castle CVE 时，自动化代码分析的特征非常明显。

显而易见的含义是，这对双方都有影响。相同的技术同样可供想要使用它的人在相同的代码库上使用，防御者并没有独占的访问权。

不太明显的影响，也是我想强调的，是它给维护者带来的负担。生成一个看似合理的漏洞报告现在几乎是免费行为。对其进行分类却不是。仍然需要人类专家投入真实时间。开源安全团队通常规模小且多为志愿者，正承受着大量质量参差不齐的报告。好的报告，如前文提到的研究，附带可复现的代码和补丁。差的报告则相当于对依赖你的人的拒绝服务攻击。如果你的组织在开源代码上部署 AI，请为另一端的分类工作提供资金。

我认为注意力被误导的地方在于：AI 并不会为你的系统打补丁。它不会清点你的资产、轮换凭证、淘汰不受支持的硬件，也不会让某人对下个月到期的证书负责。组织在购买 AI 安全工具的同时仍在运行已知存在未修补漏洞的软件，这种顺序是错误的。乏味的工作仍然是风险所在。

许多组织在工具上投入巨资，却仍因配置错误、系统老旧、流程薄弱或应急准备不足而易受攻击。您仍常见的最具影响力的安全失误是什么？在真正遭受攻击之前，领导团队应具备哪些准备？

最具影响力的错误是把安全当作采购活动来对待。工具被采购，预算得到满足，仪表盘显示绿色，却没有人问组织是否真的能够执行基本的安全措施。

第二个错误是不了解自己在运行什么。你无法为未知的软件打补丁，大多数组织在发生事故时才发现其资产的真实内容。这也是为什么材料清单工作重要，它不是合规产物，而是当关键通告发布、有人询问你是否受影响时，你在凌晨两点会求助的东西。

第三个错误是默认设置。系统被安装后即可使用，配置从未再次审视。五年后，这些配置成为负债，而最初的决策者早已不在公司。

第四个错误是将密钥和证书管理交给个人。相当比例的自招故障是由于过期证书导致的，这些证书往往由某人在电子表格中悄悄跟踪，直到其离职。

在事故发生前，领导层需要具备四项要素：一位拥有权力在必要时将业务下线的指定决策者，事先书面确定，因为关于谁有此权力的争论不应在危机时出现；已签署的外部取证和专业顾问保留合同，因为采购这些服务需要数周时间，而你只有数小时；一条不依赖可能被攻破系统的通信渠道；以及已经端到端测试过的恢复能力，而不是仅在作业成功完成的意义上验证的备份机制。

随后进行演练。每年一次的高层桌面演练会比再添一款工具更能暴露真实的缺口。

当严重网络攻击发生时，管理层可能需要在巨大的压力下同时做出技术、法律、运营和沟通决策。是什么因素使得一些组织能够有效响应，而另一些组织的事件却演变得更为严重？

处理得当的组织在事故发生前已经做好关键决策，因此在事故中能够执行而不是反复讨论。这是核心所在。

除准备外，有几项因素始终将优秀响应与糟糕响应区分开来。

他们将技术调查与高层及沟通轨道分离，并在两者之间设定明确的接口。当同一批人既要遏制入侵又要起草客户通知时，两项工作都会做得很差。

他们在修复之前先保留证据。立即重建被攻击机器的冲动很强，但会毁掉确定影响范围所需的信息。如果你无法回答“他们还触及了哪些内容”，就无法可信地告知任何人事件已经结束。

他们接受早期信息是暂时的，并据此沟通。大多数我观察到的声誉损失并非源于泄露本身，而是源于自信的早期声明随后被撤回。说“这是我们已知的情况，这是我们尚未了解的情况，何时会更新您”，并不是软弱，而是唯一不需要后撤的立场。

关键在于：他们营造了让工程师能够向高层传递坏消息的环境。我见过的最常见的失败模式是，法律风险如此明显，以至于没有人愿意写下实际发生的情况。于是事件在沉默中恶化。如果你的工程师在管理自己的责任而不是处理事件，那么你面临的治理问题是任何工具都无法解决的。

OpenSSL 作为关键的开源基础设施，贯穿整个技术生态系统，而 OpenSSL Corporation 则专注于为商业社区服务，OpenSSL Foundation 则独立运作。您如何在安全性和兼容性决策可能影响互联网大部分用户的情况下，平衡企业、开发者、监管机构和更广泛开源社区的需求？

诚实的答案是，你不能通过让每个人在每个决定中都满意来平衡它们。你通过制定并可预测地执行已公布的政策来平衡，这样即使有人不喜欢特定结果，也能据此进行规划。

可预测性是我们对用户的承诺。我们在四月和十月发布功能版本。我们提前声明哪个版本是长期稳定版以及支持期限。我们在重大删减发生前提前公告。4.0 中的 ENGINE 删除在发布前数月就已公开，并得到公司和基金会的共同同意。四月时对其感到惊讶的人显然没有关注，我们已尽可能让关注变得容易。

结构性的答案就在于这种分离。基金会的职责是服务开源库及其社区。公司则服务于具有商业需求的组织（支持承诺、FIPS 验证、特定时间线），并确保整体的财务可持续性。保持两者独立意味着任何一方的需求都不会在另一方的利益下悄然得到解决。当企业需求与社区需求真正冲突时，这种冲突发生在两个职责明确的组织之间，而不是在同一个人的脑袋里。

另一部分是正确倾听，这需要实际的机制而非假设。这也是我们举办 the conference 的重要原因，会议将在今年十月于布拉格举行，以及社区基础设施存在的原因。维护者很容易对用户需求形成自信的理论，而亲自与他们面对面交流则更有价值。

展望未来十年，您认为组织仍在低估的安全或密码学转型是什么？从 SSL、OpenSSL 的演进以及过去三十年的互联网安全经验中，领导者在准备时应汲取哪些教训？

我认为最被低估的转型并非后量子密码学本身的算法问题，而是机器身份以及其之下的证书体系。

后量子密钥交换将在默认设置下基本解决，而且大部分已经实现。无法通过默认设置解决的是信任基础设施：硬件中的根证书、固件签名密钥、仍有十年剩余寿命的 HSM、以及将在 2040 年仍在运行、在制造时已嵌入密码假设的工业和医疗系统。这些无法通过发布新库版本来更新，某些情况下根本无法更新。其更换规模目前并未体现在任何组织的资本规划中。

与之并行的是监管转型。欧洲的《网络弹性法案》以及其他地区的类似框架，将改变向客户交付包含未自行编写组件的软件的义务。大多数组织尚未厘清这对其对开源依赖或维护者的影响。

三十年的三条经验教训：

1. 转型比宣布的时间多出十年。 SSLv3 在 2015 年被废弃，2016 年默认禁用，直到 2026 年四月我们才最终移除代码。也就是十一年，针对一个大家一致认定已破损的协议。规划后量子迁移时应考虑这一现实，而不是新闻稿的时间表。
2. 默认设置是唯一在规模上有效的安全控制。 任何需要每位管理员做出正确决策的措施都不可能实现。混合后量子密钥交换之所以能快速部署，正因为它默认开启且无需任何决策。为那些永远不会阅读文档的人设计，因为几乎所有人都是这类。
3. 你依赖的人比想象的更少。 全球几乎每个组织都依赖少数几位维护密码代码的个人。这在我们两人在布里斯班时就已成立，尽管风险规模已提升数十倍，结构并未根本改变。无论你在未来十年计划什么，都会有一部分依赖于你从未联系、也未资助的维护者。这一点在需要他们之前就值得了解。

感谢这次精彩的采访。想了解更多的读者请访问 OpenSSL。