GoAhead TLS 漏洞允許被吊銷的客戶端憑證並能解密會話
GoAhead TLS Flaws Allow Revoked Client Certificates and Enable Session Decryption
GoAhead TLS 伺服器存在漏洞，允許被吊銷的客戶端憑證繞過驗證，並可能導致會話解密。
- 漏洞核心：在使用 OpenSSL 後端並啟用相互 TLS 的情況下，伺服器載入吊銷清單但未啟用吊銷檢查，導致被吊銷的憑證仍能通過驗證。
此漏洞揭示 TLS revocation 檢查缺陷，提醒裝置製造商即時升級至 GoAhead 6.1.1，確保網路安全。
譯文尚未完整，完整內容請切換至原文。
The GoAhead embedded web server loaded a certificate revocation list into its default TLS backend but never turned revocation checking on, so a revoked client certificate could still pass login on affected setups.
The flaw is in builds that use the OpenSSL backend with mutual-TLS, where the server checks a client certificate and vice versa, and a revocation list is configured to block revoked certificates.
That is a setup an operator turns on deliberately; a default build does not. GoAhead 6.1.1, released to device makers on August 2, 2026, and publicly published on October 12, fixes it.
GoAhead is a small web server that device makers build into firmware to run management pages on routers, printers, gateways and industrial controllers. Its maker, EmbedThis, says it runs in hundreds of millions of devices.
The flaw was found by Sébastien Féry of FoxIO, who described it and two other TLS problems in a write-up on October 26.
On an affected build, the server loads the revocation list file at startup and reports no error, so an operator who configured it has every reason to think revocation is working. It is not. A client whose certificate was revoked, for example a stolen or retired device, completes the handshake as if the certificate were still valid and gets whatever access that identity allows.
In FoxIO's test against GoAhead 6.1.0 with OpenSSL 3.6.2, a revoked certificate was accepted with issuer checking switched on.
The OpenSSL advisory describes revoked client certificates as silently accepted. To be exploited, the build must use the OpenSSL backend with client certificates required, a trusted certificate authority bundle and issuer checking enabled, and a revocation list configured; the attacker must hold a certificate signed by a trusted authority and listed as revoked. Builds that use the Mbed TLS backend are unaffected; that backend checks revocation via a separate code path.
The identifier on the advisory is CVE-2026-115881, rated 9.1 by EmbedThis. As of October 27, that identifier and the others below were not yet live in the public CVE and NVD databases; EmbedThis says it has requested them. The severity ratings are the vendor's own.
Researchers cover two further problems, each tied to a specific TLS build. The versions and fixes differ, so the table below maps each by backend.
| TLS build | What goes wrong | Affected versions | Fix or interim option |
|---|---|---|---|
| OpenSSL (default) | Revocation list loaded but never enforced; revoked client certificates accepted. CVE-2026-115881, rated 9.1. | 3.4.5 through 6.1.0 | Upgrade to 6.1.1. No interim option in the advisory. |
| LibreSSL legacy verifier (3.2.x, 3.3.2–3.3.6) | A client certificate chain longer than the limit is accepted when client certificates are required but issuer checking is off. CVE-2026-115884, rated 7.4. | 6.1.0 and earlier on those LibreSSL versions | Upgrade to 6.1.1, or turn issuer checking on with a trusted CA bundle, or use OpenSSL or LibreSSL 4.x. |
| Mbed TLS | A length typo sends a 1-byte Diffie-Hellman value instead of the full 2048-bit one, so a passive observer can decrypt the session. Rated 5.9. No CVE assigned. | 4.0.2 through 6.1.0 | Upgrade to 6.1.1, turn off finite-field DHE suites, or use the OpenSSL backend. |
Mbed TLS 的問題只有在客戶端接受破損的設定時才會影響會話。OpenSSL、目前的 Go、目前的 Java 以及主流瀏覽器都會拒絕如此小的值，並回退到更強的金鑰交換，因此會話永遠不會完成。
缺少最小尺寸檢查的客戶端，例如某些嵌入式或自訂版本，會接受此設定，然後任何記錄到流量的人都能算出金鑰並閱讀會話。TLS 1.3 與 ECDHE 會話不受影響，且 Mbed TLS 4.x 已移除其依賴的金鑰交換。
LibreSSL 的問題允許攻擊者提出比 GoAhead 的 10 個憑證限制更長的憑證鏈，並仍能以已驗證的客戶端完成握手，而不需要任何受信任的金鑰。
此問題僅出現在連結到上述較舊 LibreSSL 版本的建置中，且僅在要求客戶端憑證但關閉簽發者檢查的情況下。OpenSSL、BoringSSL、AWS‑LC 以及 LibreSSL 4.x 會拒絕過長的鏈。
建置使用的後端與設定是在韌體編譯時決定的，因此裝置所有者無法從外部判斷適用哪一種。這也是修正推出緩慢的原因：GoAhead 6.1.1 是一個即插即用的替代品，裝置製造商會重新編譯並以韌體更新方式釋出，所有者只有在製造商這樣做時才能取得。是否有任何製造商已釋出此修正尚不清楚。
截至 10 月 27 日，沒有任何來源報告這些問題被用於攻擊。EmbedThis 的政策是若漏洞被他人利用或披露，便結束披露禁令並提前釋出，因此協調的 10 月 12 日發布與目前已知無攻擊相符。
然而，這並不證明不存在。EmbedThis 透過其 Builder 入口網站通知客戶安全更新。FoxIO 已發布概念驗證程式碼，並透過 JA4Scan 工具提供指紋以根據後端尋找 GoAhead 伺服器。該工具免費，但其原始碼僅可按需求取得，且指紋只能識別建置，而非已確認易受攻擊的伺服器。
EmbedThis 列出的 GoAhead 使用者（包括 HP、Oracle、Siemens、Canon、Rockwell、D‑Link 與 Comcast）中，尚未證實有任何裝置製造商執行受影響的後端與設定。受影響的使用者數量尚未確定。
同一個 6.1.1 版本共關閉 11 個安全公告，其中三個評為嚴重。其一為登入繞過：在使用 HTTP Basic 或表單登入的建置中，若攻擊者知道合法使用者名稱，且該使用者的儲存密碼為新版 Blowfish 格式（GoAhead 在 6.1.0 版本加入），則可以任何密碼登入。EmbedThis 表示其內建管理頁面預設使用表單登入。
升級後，EmbedThis 建議結束正在進行的會話、重新啟動伺服器並更改 Blowfish 儲存的密碼。
覺得這篇文章有趣嗎？請在 Google News、Twitter 與 LinkedIn 追蹤我們，閱讀更多我們發布的獨家內容。