Teku 和 Besu 已在 eMudhra 事件後更新了各自的 Docker 鏡像，因為弱密鑰證書對連接外部服務的軟體構成風險，其中包括一些以太坊驗證者部署。
- Teku 26.10.3 和 Besu 26.10.2 已在 Docker 镜像中移除受 eMudhra 事件影響的證書信任。
- Teku 表示，預設的主網節點不受影響，實際暴露程度取決於 HTTPS 連線以及運營者使用的 Java 運行時。
- 披露的風險涉及被冒充的服務和驗證者操作，Teku 的通知中未報告任何被利用的情況。
對運營者來說，當前最直接的問題是：在連接其他服務時，自己的軟體是否會接受偽造證書。答案取決於所使用的連接和 Java 安裝，因此客戶端更新並不意味著每個驗證者都面臨相同風險。
Teku 和 Besu 更新 Docker 鏡像
以太坊客戶端團隊已發布更新，以修復一個起源於區塊鏈之外的證書問題。相關變更涉及軟體如何判斷遠端服務是否真實。
Teku 26.10.3 和 Besu 26.10.2 已從其 Docker 鏡像中移除對受影響證書根的信任。此版本發布是因為發現與證書頒發機構 eMudhra 相關的弱密鑰。
對於驗證者運營者而言，問題在於攻擊者冒充軟體所連接的服務。根據該服務的角色不同，偽造回應可能打亂職責，或影響某些區塊費用的支付去向。
但這並不意味著每個以太坊驗證者都處於風險之中。Teku 的安全通知指出，預設的主網節點不受影響，且目前沒有報告任何被利用的情況。
差異在於安裝方式。使用外部 HTTPS 服務的運營者，需要檢查那些在完全本地化組件部署中未必存在的連接。
這些更新適用於特定安裝環境。打過補丁的 Docker 鏡像包含了容器內打包的運行時修改，而從歸檔文件安裝的軟件則可能使用運營者另外提供的 Java。
This incident affected the infrastructure surrounding validators, but Ethereum's consensus rules remain unchanged.
為何證書問題會演變成安全風險？
憑證可幫助軟體判斷自身是否連接到預期的服務。受信任的證書頒發機構會為伺服器憑證對應的身份提供背書。
這種機制在 HTTPS 網站中很常見，但在不通過瀏覽器通信的應用中同樣適用。後台服務也可能依賴這些身份校驗。
證書頒發機構可能在受信任根證書之下使用中間證書。與這些中間證書相關的私鑰必須保持安全，因為它們可用來簽發更多證書。
在這起事件中，問題不僅僅是有人獲得了伺服器的普通登入資訊。受影響的中間密鑰可從已公開的資訊中恢復出來。
Go 安全團隊的說明指出，此弱點允許在微秒級別恢復私鑰，並指出攻擊者隨後可為其並未控制的網域建立證書。
如果某個易受攻擊的應用程式認為該證書最終仍可追溯至其信任的機構，就可能接受該證書。這樣一來，偽造身份就可能繞過原本用於拒絕冒充者的檢查。
不過，攻擊者仍然需要某種方式攔截或重定向受害者的連接。弱密鑰並不會自動讓他們出現在每個用戶與每台伺服器之間。
此條件縮小了攻擊發生的方式，但並不能讓憑證失效變得無害。只要軟體將冒充者當作真實端點，網路攔截就會變得更危險。
Kudelski Security 的研究審視了受影響的證書層級。問題在於，軟體可能接受由攻擊者能夠複現的密鑰簽發的證書。
eMudhra 將弱密鑰歸因於處理錯誤
eMudhra 的事件聲明稱，一名研究人員於 10 月 17 日報告了 8 個弱中間密鑰。公司於次日吊銷了這 8 個密鑰。
公司表示，這些中間證書是在 2025 年 4 月 30 日的一次密鑰儀式中生成的。按照公司的說法，存在缺陷的 wrap 和 unwrap 步驟在原本強密鑰之外又生成了弱副本。
公司稱使用了經過認證的硬體安全模組，並將故障歸因於周邊流程中的某一步，而非缺乏此類設備。
公司還表示，其中 7 個中間證書從未用於生產環境，剩餘的 1 個也尚未簽發證書。公司稱此次事件沒有造成基礎設施被入侵或數據洩露。
這些說法解釋了 eMudhra 對其內部運作的描述。但軟體供應商仍需應對另一種可能性：其他方可能利用可恢復的密鑰。
證書系統不能僅依賴原始運營方承諾不再簽發任何內容。一旦他人也能複製某個簽名密鑰，這種保證便無法控制所有可能創建的證書。
因此，應對措施已超出生成密鑰的那家公司。瀏覽器廠商、作業系統供應商和程式語言團隊都需要考慮其用戶的軟體會接受什麼。
這些修復將透過不同更新傳遞給用戶。瀏覽器可能收到封鎖名單，而另一個獨立的 Java 應用程式仍可能繼續使用舊的受信任憑證集。
弱密鑰和接受該密鑰的應用是同一問題的兩個不同部分。吊銷證書解決的是機構記錄層面的問題，而客戶端還需要一種可靠方式來識別自己應該拒絕受影響的信任路徑。
外部服務為驗證者帶來不同風險
以太坊節點由承擔不同職責的軟體組成。以太坊客戶端文檔區分了執行客戶端和共識客戶端：前者處理交易執行和狀態，後者遵循權益證明共識。
驗證者軟體增加了提議區塊和為鏈提供證明的職責。運營者可在本地運行這些組件，或透過外部服務連接其中一部分。
Teku 是共識客戶端，Besu 是執行客戶端。兩者均使用 Java，這也是為何其運行時的證書信任與其發行版本相關。
除本地機器外，其他服務會為此安排增加一重身份驗證。軟件需要確認響應請求的端點就是預期的提供方。
例如，運營者可能使用遠端簽名服務，而不是將簽名操作保留在同一個進程中。也有人可能依賴外部端點提供資料或區塊建構服務。
冒充者能造成的損害程度，取決於該服務被允許執行的操作。僅接收監控數據的服務，與參與簽名決策的信息提供服務，風險並不相同。
網路路徑同樣重要。透過公共基礎設施的連接，與僅限於同一主機或受嚴格控制的私有網路中的組件相比，攔截機會不同。
Private networks cannot prevent all failures from occurring, but they can reduce the chances of attackers gaining the locations needed to disrupt traffic.
因此，僅憑客戶端名稱並不能判斷是否暴露。相同的軟體可以部署在使用不同端點、信任庫和存取控制的環境中。
真正需要回答的問題是：哪一條連接通過了受影響路徑接受證書。一旦明確這一點，運營者就能評估被冒充的服務在驗證者運作中本應擁有什麼樣的權限。
為什麼 Docker 鏡像和歸檔安裝不同？
Docker 镜像會將應用程式及其運行所需的環境一併打包，其中可能包括 Java 運行時以及該運行時所信任的證書。
更新主機上的 Java，並不會自動替換現有鏡像中的 Java。容器仍可能繼續使用自己打包的檔案。
這就是客戶端發佈說明中特別提及 Docker 變更的原因。Teku 的說明指出，當時其 Eclipse Temurin 基礎鏡像尚未包含相關移除，因此客戶端鏡像直接進行了修改。
Besu 的發佈說明同樣指出，其證書移除適用於 Docker 鏡像，並明確要求安裝用戶檢查自己提供的 Java 發行版。
歸檔安裝會將此責任留給運營者。以太坊客戶端可能已更新，但其獨立的運行時仍可能包含舊的證書儲存。
相反，在維護過程中也會出現類似的區別。更換主機運行時會影響使用該運行時的進程，但不會影響另一個使用不同 Java 路徑的安裝。
Oracle 的事件指引建議用戶更新受影響的運行時，或遵循其文件中提供的替代方案。它還要求重啟正在運行的實例，並分別考慮每個獨立安裝。
這使得正在運行的進程比下載到的更新更重要。伺服器可以包含已打補丁的檔案，但舊進程仍會繼續運行，直到被替換或重啟。
自訂證書儲存又增加了一種變化。某個組織可能使用的是為自身服務維護的證書庫，而不只是 Java 預設提供的證書庫。
實際任務是找出客戶端真正使用了什麼。安裝方式、運行時位置和信任配置共同決定了已發布的修補程式是否已到達需要它的那條連接。
吊銷檢查在不同應用中的差異
吊銷意味著證書不應再被接受。但這並不保證每個應用在建立連接前都會檢查最新的吊銷資訊。
不同應用獲取這些資訊的方式也不同。有些會查詢線上服務，有些使用供應商提供的封鎖名單，還有些主要依賴本地信任庫中的憑證。
Go 團隊的回應說明了為何運行時供應商可能需要直接介入。該團隊於 10 月 19 日啟動了緊急安全發布，並表示在收到通知後約 7.5 小時內即提供了修補版本。
此操作阻斷了受影響證書路徑中涉及的相關 Go 驗證行為應用。Java 用戶則需透過其自身的運行時和信任設定獲得保護。
Teku 的通知指出，Java 預設不會檢查吊銷。這也是為什麼即使 eMudhra 已經吊銷了這些中間證書，仍有必要在本地移除信任。
根證書移除和中間證書阻斷也可能作用於不同層面。前者拒絕某一條特定的受損路徑，後者則可以拒絕通向被移除根證書的更廣泛證書鏈。
正確的實現屬於供應商和維護應用的組織。若臨時採取一種禁用身份驗證的做法，只會移除保護，而不是解決信任問題。
合法服務也可能需要調整。如果它們的憑證依賴於客戶端現在拒絕的路徑，那麼服務方必須提供可接受的替代方案，而不是指望用戶恢復不安全的信任。
這也解釋了為何一次證書事件可能會持續數天。發現可能是即時的，但防護會透過瀏覽器、封裝應用程式和私有基礎設施的不同發布與維護流程逐步到位。
對於驗證者運營者而言，關鍵結果是相關連接是否已拒絕不受信任的身份。軟體生態中其他地方的撤銷公告，並不能證明其節點進程已達成此結果。
獎勵和驗證者質押是否以同樣方式暴露？
驗證者的質押、簽名職責和費用支付彼此相關，但它們受不同機制約束。影響其中一項的問題，不應自動被描述為對所有這些內容的控制。
以太坊質押文件說明：驗證者透過履行職責獲得獎勵，並會因離線或可證明的不當行為而受到懲罰。簽名權限與提款權限在系統中扮演不同角色。
證書密鑰屬於用於連接的身份系統。它並非驗證者的私有簽名密鑰，也不會直接洩露管理已質押 ETH 提現的憑證。
不過，被冒充的服務仍可能影響驗證者的行為。其影響取決於該服務處理哪些請求或回應，以及還保留了哪些額外檢查。
區塊提議包含執行相關支付的費用接收方。若某條路徑能夠修改提議或配置，就可能產生後果，而不必控制整個質押。
簽名服務又提出另一組問題，因為它參與授權驗證者行為。其自身的保護措施，包括對請求的限制以及防止衝突簽名的保障，都會影響攻擊者能達成的程度。
因服務中斷導致的職責遺漏也是一種可能後果。即使沒有成功轉移任何付款，攻擊者只要阻止正確回應，也可能減少獎勵。
這些結果的財務影響並不相同。錯失提議區塊的機會、普通離線處罰和削減處罰，不能混為一談。
客戶端公告描述的是在受影響配置下可能出現的後果，並未證明每個運營者都遭遇了這些後果，也未證明有相應數量的 ETH 被盜。
對於使用質押服務商的持有者來說，真正相關的是服務商的實際部署。管理了多少 ETH，並不能說明其運營者使用了哪些遠端服務或證書庫。
驗證者也依賴以太坊之外的軟體
以太坊網絡規則只是運營者依賴的一部分。硬體、運行時、託管、配置和外部服務都會影響驗證者是否能正確履行職責。
證書頒發機構位於以太坊協議之外，但當驗證者軟件依賴它來識別服務時，其故障便會變得相關。僅此一點，就足以將一個通用的互聯網安全問題帶入質押基礎設施。
客戶端多樣性仍然具有價值，因為不同的實現可以減少對單一程式碼庫的依賴。但這並不意味著每個依賴項都是獨立的。
兩個客戶端可以使用相同的程式語言執行環境。不同運營者也可能使用同一家託管服務商、簽名服務或區塊建構基礎設施。
這些共享組件會在以太坊軟體本身不同的情況下，形成共同暴露面。因此，要理解部署情況，不能只看客戶端品牌數量。
外包也會帶來權衡。專用簽名服務可能改善密鑰保護方式，但也會讓與該服務的認證連接變得更加重要。
在本地運行也有其自身的維護要求。將組件放在同一台機器上可以減少部分網路暴露，但運營者仍需管理軟體更新以及對該機器的存取。
這起事件並不會自動提供一種在所有情況下都最安全的架構。它說明的是，必須理解並維護每條連接周邊的職責。
這種區別對普通 ETH 用戶也很重要。節點基礎設施中的證書補丁，並不意味著每個錢包都必須轉移資金，也不意味著以太坊帳戶餘額發生了變化。
相關行動屬於受影響的軟體運營者。他們才有能力識別所涉及的運行時、端點和信任設定，然後將供應商的相關指導應用到正在建立這些連接的系統上。
運營者需應用並檢查更新
這些發布為運營者提供了從支援的 Docker 鏡像中移除受影響信任路徑的方法。歸檔用戶則需根據各自 Java 供應商的指導，處理單獨的運行時工作。
補丁可用只是流程的第一步。更新後的環境還需要實際運行，並保持預期配置和服務正常運作。
對於服務提供方來說，由新近被拒絕的證書引發的中斷，可能需要在端點更換證書。恢復服務時應保留身份驗證，而不是繞過它。
後續披露可能會進一步細化影響。運營者也許會識別出某個接受了受影響證書鏈的配置，或報告涉及特定服務的事件。
目前，Teku 的通知報告未被利用，並區分了預設主網使用與受影響的外部連接。這是描述當前以太坊暴露面的最清晰依據。
受影響的運營者有理由更新。任何財務損失取決於攻擊者冒充了哪個服務、是否攔截了流量，以及驗證者允許該服務做什麼。
需要關注什麼
- 客戶端更新：請關注 Teku 和 Besu 的發布，並確認已運行修補後的版本。
- Java 證書：查看每個安裝所使用的 Java 運行時和證書庫的供應商指南。
- 外部連結：審查指向遠端簽名、資料和區塊建構服務的 HTTPS 連結。
- 安全通知：請留意客戶端團隊和 Java 供應商發布的確認攻擊或進一步說明。
常見問題
eMudhra 事件是什麼？
此事件涉及與證書頒發機構 eMudhra 的中間證書相關的弱私鑰。研究人員發現，這些密鑰可從公開資訊中恢復，從而可能讓他人為其並未控制的網域建立證書。信任該證書路徑的軟體可能會接受這種偽造身份。攻擊者仍需某種方式攔截或重定向連線，才能冒充目標服務。
以太坊共識是否失敗了？
沒有。報告中的問題涉及軟體如何檢查外部服務的身份，而非以太坊在區塊鏈上達成共識的規則。客戶端更新改變的是受影響軟體環境中的證書信任。某些驗證者部署若遭遇外部服務被冒充，仍可能面臨運營風險。這種可能性取決於連接和服務角色，並不意味著以太坊共識規則被破壞。
哪些客戶端已被更新？
Teku 26.10.3 和 Besu 26.10.2 已更新其 Docker 鏡像，以移除受影響的證書信任。Teku 為共識客戶端，Besu 為執行客戶端，兩者均使用 Java。安裝方式至關重要，因為此變更僅適用於這些鏡像中提供的環境。若運營者安裝的是客戶端歸檔檔並自行提供 Java 運行時，則需單獨查閱該運行時的相關指引。
Will all validators be affected?
不會。Teku 的通知指出，預設的主網節點不受影響。風險取決於某個部署是否進行了相關的外部 HTTPS 連接，以及其證書檢查是否接受受影響的信任路徑。不同的運營者可以在不同的服務、Java 版本和證書庫下運行同一客戶端。因此，客戶端名稱或質押的 ETH 數量，並不能說明某個特定驗證者是否暴露。
Docker 更新能覆蓋所有安裝方式嗎？
不能。打補丁後的 Docker 鏡像會更新鏡像內打包的環境，但歸檔安裝可能使用運營者另外提供的 Java。其他容器或服務也可能有自己的運行時。運營者需要識別正在運行的進程使用的是哪種安裝方式，並遵循其供應商說明。伺服器上的已打補丁文件，並不能保護仍在舊環境中運行的進程。
是否已確認被利用？
在本文所述時間點，Teku 的通知沒有報告被利用。相關披露描述的是一個弱點及其可能後果，而不是證明攻擊者已經將其用於驗證者。討論損失時，這一區別很重要。存在一條冒充服務的可能路徑，並不等於簽名職責被操縱、費用支付被轉移或質押 ETH 被盜。
驗證者存款會自動暴露嗎？
不會。證書簽名密鑰不同於驗證者簽名密鑰，也不同於控制提現的憑證。恢復受影響的證書密鑰，並不會自動洩露提取質押 ETH 所需的密鑰。被冒充的服務仍可能打亂職責或影響驗證者使用的資訊，具體取決於部署方式。應針對該服務評估可能後果，而不是將其視為對整個存款的自動訪問。
運營者應該怎麼做？
運營者應遵循相關 Teku 或 Besu 發布說明，以及其 Java 發行版的指導。需識別每個受影響進程所使用的運行時和證書庫，包括容器內提供的部分。應用建議更新後，應確認更新後的服務正在運行，且所需連接仍可正常工作。為恢復失敗連接而禁用證書檢查，將移除這些檢查本應提供的保護。