一个已经被吊销的客户端证书，照旧能登进设备的管理后台——不是没人配吊销名单（CRL），而是清单装进去了，「检查」那一步从来没打开。
出事的叫 GoAhead，一个很小、很老的嵌入式 web 服务器。名字陌生很正常，它藏在设备的固件里干活：路由器、打印机、网关、工业控制器，跑的就是它们那些管理页面。开发商 EmbedThis 的说法是，跑着它的设备有数以亿计。
洞是这么来的：GoAhead 会把一份证书吊销名单（CRL）加载进默认的 TLS 后端，但没把「吊销检查」这个开关打开。于是在双向 TLS（mTLS）里，「这张客户端证书已经被吊销、不许放行」那条判断，实际上是空的——被吊销的证书照样能通过登录。
触发条件得说清楚，因为它并不泛化：用 OpenSSL 后端、开了双向 TLS、还特意配了 CRL 去拦吊销证书的那种构建才中。这套配置是运维主动打开的，默认构建根本不满足。也就是说，越是认真上了 CRL 想防吊销证书的，越容易踩上。
发现它的是 FoxIO 的 Sébastien Féry，他在 10 月 26 日的一篇分析里一并写了 GoAhead 另外两个 TLS 问题（其中一个能导致会话被解密）。
影响版本：使用 OpenSSL 后端、启用双向 TLS 且配置了 CRL 的 GoAhead 构建（6.1.1 之前）。
修复版本：GoAhead 6.1.1——8 月 2 日就已交给设备厂商，10 月 12 日公开发布。麻烦在于它躺在固件里：能不能升、什么时候升，取决于设备厂商，不取决于你。
一条自查：翻你手上设备的管理页或固件版本，看是不是还跑在 GoAhead 6.1.1 之前的构建；凡是开了 mTLS + CRL 的设备，优先去问厂商有没有跟进。
这个洞本身不算大，但它戳中的事不小：安全配置「存在」和「生效」，是两码事。CRL 装进去只是一份数据，吊销检查那道逻辑不走，名单再全也是摆设。OCSP、白名单、密码策略，都是一个道理——配好了不等于拦住了，得验它真的在拦。
我之前写过一台机器 binlog 明明配了过期时间，还是涨到 7 个 G，同一类味道：配置项在那儿，逻辑没走到。证书这块也值得记一句，上次 SSL 报错 curl: undefined symbol，折腾半天也不是证书本身的问题，是两个 libcurl 在抢位置。运维里「我以为我配了」翻的车，比「我不知道要配」多得多。
原文：The Hacker News《GoAhead TLS Flaws Allow Revoked Client Certificates and Enable Session Decryption》：https://thehackernews.com/2026/10/goahead-tls-flaws-allow-revoked-client.html
评论