GoAhead 三項 TLS 漏洞曝光與修補建議

TLDR

GoAhead 被用於數億臺 IoT、Firewall、OT 及軍事裝置，包括 Palo Alto Networks、Comcast、D-Link、HP、Canon、Honeywell、GE、Oracle、Siemens、Rockwell、Digi、Lockheed Martin、Boeing 等等。

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 build	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 是一個嵌入式網頁伺服器，用於裝置管理：路由器、交換機、印表機、閘道器及工業控制，已部署於數億臺裝置。

以下每項發現影響特定子集的部署，取決於構建與設定。

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 在未檢查載入清單的情況下回傳成功。應用程式的回呼會在其 default: 分支中以錯誤 23、X509_V_ERR_CERT_REVOKED 拒絕，但驗證器從未產生該錯誤。

在 GoAhead 6.1.0 與 OpenSSL 3.6.2 上，撤銷的 CA 簽署的客戶端憑證即使啟用發行者驗證也完成了 mTLS 握手。驗證回呼在整條鏈中報告錯誤 0：

X509_STORE_load_locations() 成功，啟動時不會產生 CRL 執行失效的警告。

Affected: GoAhead 3.4.5 至 6.1.0 使用 OpenSSL 相容後端並設定 CRL。安全影響最明顯的是 VERIFY_PEER=1、受信任的 CA 套件，以及 VERIFY_ISSUER=1：先前受信任但已撤銷的身份仍保有存取權。當停用發行者檢查時，CRL 缺陷仍在，但未知發行者已被政策接受。

Fix: 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 位元組值。

損壞的引數僅留下八個可能的共享金鑰值：01、02、04、08、10、20、40 和 80（十六進位）。觀察者可嘗試每個候選值，並檢查其是否能成功解密捕獲的流量來判斷正確值。

在附加的 PoC 中，我在五次嘗試後成功重現共享金鑰。它與客戶端的金鑰相符，證實可使用相同的 TLS 會話金鑰來解密 HTTP 交換。

被動觀察者可使用已記錄的握手和加密的應用程式記錄，完全離線解密已捕獲的會話。

利用需要能接受損壞 DH 引數的客戶端。測試的 OpenSSL 客戶端以 DH_check_params_ex: modulus too small 拒絕它們。寬容型客戶端，包括未檢查最小尺寸的自訂或嵌入式實作，能完成可解密的會話。ECDHE 會話和 TLS 1.3 不受此已設定有限域群組的影響。

Affected: GoAhead 4.0.2 至 6.1.0 使用 mbed TLS 後端並啟用 TLS 1.2 DHE_RSA 套件，客戶端接受引數。2018 年在遷移至二進位引數 API 時輸入的打字錯誤，並在 2024 年 4 月的 TLS 重構中存活。Mbed TLS 4.x 已移除 TLS_DHE_* 套件，因此此 DHE 路徑不受影響。

若您在環境的 JA4S 日誌中看到任何這些套件，您可能受影響（例如 t120100_009f_1ca028f07214）

您可能想執行的範例查詢（在 Splunk 或其他工具中）如下：

將 0014 替換為上述列出的曲線。

Fix: 6.1.1 已修正打字錯誤

LibreSSL 版本

基本上，攻擊者可以提供超過 GoAhead 限制的憑證鏈，並在受影響的建置上完成 mTLS 握手。LibreSSL 會報告發行者錯誤而非深度錯誤。GoAhead 在停用發行者檢查時會接受該發行者錯誤。

GoAhead 6.1.0 以 SSL_CTX_set_verify_depth(sslctx, VERIFY_DEPTH) 設定鏈深度限制為 10。其驗證回呼也會檢查深度：

此檢查僅在 ok 為真、報告的深度超過限制且尚未存在錯誤時才指派深度錯誤。回呼隨後將錯誤分類為：

錯誤 20，UNABLE_TO_GET_ISSUER_CERT_LOCALLY，在停用發行者檢查時會被容忍。錯誤 22，CERT_CHAIN_TOO_LONG，則會被拒絕。

LibreSSL 3.2.x 與 3.3.2–3.3.6 預設使用舊版 X.509 驗證器進行對等驗證。其鏈組建迴圈包含一個 FIXME 註解（這也是最初促使檢視 GoAhead 的原因）：

該迴圈在未記錄深度錯誤的情況下停止構建鏈。隨後失敗以錯誤 20 到達 GoAhead。使用 VERIFY_ISSUER=0 時，回撥會接受它。

在與 LibreSSL 3.3.6 連結的 GoAhead 6.1.0 上，根據攻擊者控制、自己簽署的 CA 的 17 份憑證鏈產生了以下回調追蹤：

握手完成，並且滿足客戶端憑證要求的資源回傳 HTTP 200。相同的 GoAhead 原始碼在 LibreSSL 4.3.1 下編譯時，於深度 10 收到錯誤 22，並拒絕該鏈。

使用 VERIFY_ISSUER=0 時，普通自簽憑證已被允許。過深鏈繞過了獨立的鏈深度限制，因為驗證器報告了可容忍的簽發者錯誤。需要可信客戶端 CA 的部署會拒絕它。

示範配置： GoAhead 6.1.0 搭配 LibreSSL 舊版驗證器、ME_GOAHEAD_SSL_VERIFY_PEER=1 與 ME_GOAHEAD_SSL_VERIFY_ISSUER=0。啟用簽發者信任會拒絕錯誤 20。OpenSSL、BoringSSL、AWS-LC 與 LibreSSL 4.x 版本不會受到此舊版驗證器觸發。

結論

上述三項發現均影響 GoAhead 與其 TLS 函式庫的整合。CRL 執行取決於驗證旗標，DH 引數取決於所提供的緩衝長度，鏈深度執行取決於驗證錯誤的處理方式。這些缺陷均未阻止受影響的握手完成。

後端與建置設定決定適用哪些缺陷。LibreSSL 版本可同時繼承 OpenSSL 相容後端的 CRL 缺陷與舊版驗證器的深度問題。mbed TLS 後端使用獨立的驗證路徑，但在客戶端接受引數時會受到 DH 截斷的影響。

為尋找您機群中受影響的公開伺服器，以下列出對應不同後端的 JA4Scan-TLS 指紋：

伺服器 (GoAhead 6.1.x)	JA4Scan-TLS
OpenSSL 3.6.2	03100h0s00sn_1fe27f6025fb_d06dc4648d2f_sr00ss537461
LibreSSL 3.3.6	03100h0s00s0_9d52559f55bc_c64486648d2f_sr00sc24603c
LibreSSL 4.3.1 (深度繞過未受影響)	03100h0r00s0_9d52559f55bc_c64486206461_sr00scc98ba1
mbedTLS 3.6.6	23100h0s01s0_d7d3025021f4_0475c5cede0d_sr0ss02265cf