简而言之，GoAhead被用于数亿个物联网、Firewall、OT和军事设备中，包括来自Palo Alto Networks、Comcast、D-Link、HP、佳能、霍尼韦尔、GE、甲骨文、西门子、罗克韦尔、Digi、洛克希德·马丁、波音等公司的设备。GoAhead的TLS集成中的三个独立漏洞可能会导致被撤销的客户端证书被接受、加密会话可被观察者恢复，或者配置的链深度限制未得到执行。曝光程度取决于TLS库和设备内置的验证设置：OpenSSL兼容后端 - 严重，CVSS 9.1 - CRL已加载但未执行，被撤销的客户端证书会被默默接受。GOAHEAD-SA-2026-0006。LibreSSL遗留验证器 - 高，CVSS 7.4 - 在需要客户端证书但禁用颁发者检查时，接受深度过大的客户端链。绕过链深度限制。GOAHEAD-SA-2026-0004。Mbed TLS - 中等，CVSS 5.9 - 缓冲区长度拼写错误将2048位DH模数减少到一个字节。当客户端接受这些破损的参数时，TLS 1.2 DHE_RSA会话是可解密的。GOAHEAD-SA-2026-0005。TLS构建 GoAhead版本 所需配置 修复或缓解措施 OpenSSL兼容后端 >= 3.4.5, <= 6.1.0 启用mTLS并配置CRL。即使启用颁发者验证，被撤销的客户端证书也会被接受。升级到6.1.1或更高版本。 Mbed TLS后端 >= 4.0.2, <= 6.1.0 TLS 1.2 DHE_RSA与接受破损DH参数的客户端协商。升级到6.1.1或更高版本，禁用有限域DHE套件，或使用OpenSSL后端。 LibreSSL遗留验证器 — 3.2.x或3.3.2–3.3.6 <= 6.1.0 VERIFY_PEER=1和VERIFY_ISSUER=0。接受深度过大的客户端链。启用具有受信CA包的VERIFY_ISSUER=1，或使用OpenSSL / LibreSSL 4.x。 背景 GoAhead是用于设备管理的嵌入式Web服务器：路由器、交换机、打印机、网关和工业控制，已部署于数亿设备中。以下每个发现影响特定的子集，具体取决于构建和配置。GoAhead支持两个TLS后端：OpenSSL，默认值，和MbedTLS。OpenSSL后端还与兼容库（例如LibreSSL）一起工作。GoAhead在某些配置方面采取编译时方式：- ME_GOAHEAD_SSL_VERIFY_PEER=1要求客户端证书。- ME_GOAHEAD_SSL_AUTHORITY指向已信任CA的PEM包。- ME_GOAHEAD_SSL_VERIFY_ISSUER=1要求证书链建立对该包的颁发者信任。- ME_GOAHEAD_SSL_REVOKE指向PEM编码的证书撤销列表。- OpenSSL后端设置10的链深度限制（VERIFY_DEPTH）。 OpenSSL兼容构建 GoAhead的OpenSSL后端将已配置的CRL加载到证书存储中，但从未启用撤销检查。因此，即使启用颁发者验证，被撤销的客户端证书仍然可以完成mTLS握手。CRL在sslOpen()中加载：OpenSSL要求X509_V_FLAG_CRL_CHECK以启用CRL检查。将文件加载到存储中不会设置该标志。在未启用CRL或OCSP检查的情况下，check_revocation()在检查撤销状态之前返回成功：GoAhead永远不会设置任何CRL标志。OpenSSL在未检查加载列表的情况下返回成功。应用程序的回调将通过其默认分支拒绝错误23，X509_V_ERR_CERT_REVOKED，但验证器永远不会生成该错误。在使用OpenSSL 3.6.2的GoAhead 6.1.0上，撤销的CA签名客户端证书在启用颁发者验证的情况下完成了mTLS握手。验证回调在整个链上报告错误0：X509_STORE_load_locations()成功，因此启动不会生成CRL强制执行未激活的警告。 受影响的版本：使用OpenSSL兼容后端并配置有CRL的GoAhead 3.4.5至6.1.0。安全影响在设置为VERIFY_PEER=1、受信任CA包和VERIFY_ISSUER=1时最为明显：先前受信的但被撤销的身份仍然拥有访问权限。当禁用颁发者检查时，CRL缺陷仍然存在，但已接受未知颁发者的政策。 修复：6.1.1现在在加载CRL后进行检查：Mbed TLS构建 GoAhead的mbed TLS后端通过mbedtls_ssl_conf_dh_param_bin()配置RFC 3526 2048位DH组。传递给该函数的模数长度取自生成器缓冲区：大小参数告诉mbed TLS从每个缓冲区读取多少字节。该调用将sizeof(dhm_g)用于两者，即使dhm_g仅为一个字节。dhm_p的长度应该是sizeof(dhm_p)，或256字节。结果，mbed TLS仅读取dhm_p的第一个字节：0xFF（255）。剩余的255字节被丢弃。它接受此值并在TLS 1.2 DHE_RSA握手期间将其发送给客户端：在ServerKeyExchange中，00 01 ff标识了一个值为255的一字节DH参数。它应该包含完整的256字节值。