文章总结： OpenSSL错误处理缺陷导致Debian13系统上apt3.0在FIPS模式下无法进行HTTPS访问。问题根源在于apt的TLS读写路径未在调用SSLgeterror前清空OpenSSL的每线程错误队列，误将残留的旧错误当作当前操作结果。该编码捷径在生态系统中普遍存在，可能掩盖真实的安全检查失败。修复建议包括针对性清空错误队列或使用ERRsetmark和ERRpopto_mark包裹代码块。 综合评分： 88 文章分类： 漏洞分析,安全开发,技术标准,解决方案

OpenSSL 错误处理缺陷导致 FIPS 模式下 apt 无法进行 HTTPS 访问

sec随谈 sec随谈

sec随谈

2026年7月7日 09:18 北京

在小说阅读器读本章

去阅读

摘要

一位 Debian 维护者指出了在开源生态系统中普遍存在的 OpenSSL 错误处理问题。该问题最初是在纯 FIPS 模式系统上因 apt 无法访问 HTTPS 软件源而被发现，随后被追溯到一种常见的编码”捷径”（shortcut）写法。目前该报告尚未关联任何 CVE 编号，也没有发现被主动利用的情况。

为何重要

互联网上大部分 TLS 流量都依赖于 OpenSSL。因此，错误处理方面一个共有的不良习惯就可能波及众多工具。apt 的维护者 Julian Andres Klode 警告称，这种模式影响了生态系统中相当大的一部分。其影响程度从轻微到严重不等，因为某些被丢弃的错误可能与安全相关——一条被丢弃的错误队列条目，可能掩盖了真实存在的证书或签名验证失败，从而使一次本应中止的安全检查悄无声息地被放行。在 oss-security 披露邮件中，Klode 敦促开发者对自己的代码进行审计。

漏洞原理

问题的根源在于 OpenSSL 的每线程错误队列（per-thread error queue）机制。在 TLS 握手过程中，libssl 会尝试获取传统的 MD5 摘要算法；而在纯 FIPS 模式的环境下，这一获取操作会失败，并在队列中留下一条陈旧但无害的错误记录，尽管此时握手本身仍能顺利完成。

而 apt 的处理方式则让情况变得更糟：其 TLS 读写路径在调用 SSL_get_error() 之前并未先清空错误队列。然而，OpenSSL 的官方文档要求在每次 TLS 操作之前队列必须为空。因此，当一次读取操作因某种无害原因提前返回时，apt 会误将队列中残留的旧错误当作本次操作的结果，从而报告为一次致命错误，并将其映射为 I/O 错误，最终中止下载。OpenSSL 的 issue 讨论帖详细记录了完整的排查过程。

两种不良模式

Klode 指出了两种不良习惯。第一种是：部分代码在每次操作之前都调用 ERR_clear_error()，以此掩盖之前可能存在的错误。第二种是：部分代码只检查队列顶部的错误，然后将其余错误一并清空。这两种模式都会在不知不觉中丢弃与当前操作无关的错误信息。

受影响范围

具体的触发场景出现在搭载 apt 3.0 和 OpenSSL 3.5.6 的 Debian 13 系统上。此前版本的 apt 使用的是 GnuTLS，因此从未涉及这一错误队列问题。随后，Klode 通过代码搜索发现，同样的编码捷径在整个 Debian 生态中普遍存在。除 apt 之外，这种 OpenSSL 错误处理模式也出现在许多其他项目中。

修复与缓解措施

安全的修复方式应当是有针对性的，而非一概而论：开发者应仅在已知无害的操作前后清空错误队列，正如 libpq 的做法一样。更好的方式是使用 ERR_set_mark 和 ERR_pop_to_mark 来包裹相关代码块。最根本的做法，是修复最初产生该错误的代码本身。对于 apt 而言，目前提出的补丁方案是在每次读写操作之前增加一次队列清空调用。维护者们仍在讨论 libssl 是否应当自行清空该队列。对于目前已受到影响的 apt 用户，启用默认的 OpenSSL provider 即可恢复对软件源的访问。

参考链接：

https://seclists.org/oss-sec/2026/q3/17

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：sec随谈 sec随谈 sec随谈《OpenSSL 错误处理缺陷导致 FIPS 模式下 apt 无法进行 HTTPS 访问》