eMudhra中級CA洩露：瀏覽器封鎖列表與運行時信任差距
八個eMudhra中級簽名金鑰遭到洩露，其中六個用於TLS，兩個用於代碼簽名。
八個eMudhra中級簽名金鑰遭到洩露，其中六個用於TLS，兩個用於代碼簽名。事件發生在Mozilla確認、瀏覽器封鎖和下游更新之後，解釋了為什麼已部署的應用程序需要檢查其自己的信任配置。一份單獨的Tor報告顯示SSH主機身份警告正在發揮作用。
本影片涵蓋的內容
- 洩露的金鑰屬於中級簽名者。根目錄的不信任可以在不證明根私鑰被洩露的情況下緩解鏈條。
- 瀏覽器的緊急封鎖列表和應用程序的捆綁CA存儲可以遵循單獨的更新路徑。檢查運行中的進程及其實際的信任配置。
- Mozilla獨立確認了可恢復的私鑰。報告沒有描述受影響中間體的CT條目；對其他客戶的實際濫用仍然未知。
- 主要版本驗證了所討論分支的certifi 2026.10.19和Node 24.22.1。自定義CA捆綁包和其他運行時分支需要進行自己的檢查。
- Tor研究人員的333個中繼帳戶涉及10月早些時候發布的事件。大約百分之十是中繼計數，而不是截獲流量測量。
- 單獨的網絡超時不能證明證書驗證拒絕了受損鏈。保留驗證並區分傳輸錯誤和身份驗證失敗。
翻譯的文字記錄
從英文原文旁白翻譯。可用的音頻和字幕由 YouTube 控制。
為什麼固定的瀏覽器會讓應用程式暴露？
0:00 eMudhra瀏覽器修復聽起來像是一切都沒問題。 八個受損簽名金鑰仍然讓軟體面臨過時的信任決策。 在這段影片中，誰可以簽名？ 為什麼客戶端會意見不一？ 以及哪個更新真正到達了您的應用程式？ 一個微小的依賴關係維護著自己的信任列表。 我們稍後會回到決定您的修復程式是否到達的流程。 今天是10月21日星期三，這是《每日差異》。
0:22 eMudhra是一個證書頒發機構。 它簽署數位證書，幫助軟體驗證網站和 服務。受損的金鑰包括六個用於網頁連線和兩個用於 簽名軟體。中級簽名者是受信任根之下的委派簽名者。 週五，一位名叫Wayne的記者將證據發送給了根程式。 到週二，公共事件頁面正在解釋清理工作。 今天，開發人員將發現他們的完美 正常應用程式已收集了多少個信任副本。
中級金鑰授權了什麼？
0:49 這是普通的鏈條。 網站呈現證書，中級簽署它， 您的客戶端跟隨鏈條到它已信任的根。 根是您的本地起點。 誰控制了中級簽名者的私鑰，就可以在該權限下簽名。 數學上有效的簽名可能有一個完全不可信的簽名者。 驗證者需要一種方法在洩露後撤回信任。 Wayne簽署了訊息，「我們這裡有個問題，Wayne，」
1:12 每個金鑰。 Mozilla驗證了金鑰控制權，然後獨立恢復了金鑰。 緊急響應始於一句話，聽起來像是有人注意到了 辦公室印表機正在冒煙。
哪些已證明，哪些仍然未知？
1:22 公開報告稱，金鑰生成不正確，並且可以從 去年4月創建的證書中恢復。 對其他軟體的實際濫用仍然未知。 可恢復的簽名權限在沒有虛構受害者列表的情況下已經足夠緊急了。 這裡有一個重要的限制。 報告未發現 那些中級簽名者在那段時間內的證書 透明度條目。
1:42 它說，實施透明度的瀏覽器不可能通過 此途徑受到攻擊。額外的瀏覽器檢查有助於解釋為什麼僅僅是標題 誇大了事實。 eMudhra告訴Mozilla，大約有三萬張證書需要遷移到 另一個鏈條。這些是正在運行的服務，其所有者必須在清理期間更換證書。 某處，一個日曆邀請剛剛變成了一個生產依賴項。 瀏覽器供應商發布緊急封鎖列表。
為什麼瀏覽器和運行時不一致？
2:03 報告記錄了Firefox和Chrome在週五採取的行動， 隨後是Apple和Microsoft。 這些客戶端可以拒絕受損的中級CA，同時仍識別其 根憑證。該規則與您的應用程式捆綁包獨立傳播。 有些客戶端會根據受信任的根憑證檢查鏈條，而不使用緊急 撤銷資訊。憑證頒發機構可以發布撤銷， 而該客戶端可以繼續接受該鏈條。 當訪客會讀標誌時，在門上貼標誌會更有效。
2:27 Mozilla表示，一些Android設定檔在啟動時未能應用更新的封鎖列表。 修復程式已在Firefox 158.02中發布。 所以也要保持瀏覽器更新。 此公告無法列出您的手機庫存。 當客戶端缺乏更窄的封鎖時，維護者可以移除信任錨點。 Mozilla的線程描述了對emSign ECC根，第三代，的緊急不信任。 從信任儲存中移除根憑證會阻擋依賴於它的鏈條， 即使根憑證本身的私鑰從未被洩露。
2:54 Python 最新的 certifi 發布是下游更新之一。 其提交也恢復了在早期移除後未受影響的 emSign 根。
哪些更新到達了Python和Node？
3:01 刪除所有帶有公司名稱的東西是維護包的糟糕替代品。 您希望拒絕危險的鏈條，同時讓合法的 客戶仍然能夠正常工作。 發布歷史保留了這兩個決定。 安全清理工作光鮮亮麗，既緊急 又精確，而且午餐時無論哪個服務出現故障，都會受到指責。 Node 的 24.22.1 版本今天發布，更新了 根證書。請檢查您自己的分支建議和實際的 CA 配置。
3:26 自定義捆綁包可以更改進程使用的信任儲存。 在 Tor 中，一位研究人員昨天發表了一篇關於三百三十個 三個受損出口中繼的報告。
Tor主機金鑰警告捕獲了什麼？
3:36 攔截始於本月初。 幾天後，中繼被標記並關閉，然後報告才發表。 SSH 警告研究人員，伺服器身份已更改。 他向 Tor 的網絡健康團隊報告了此事。 他們的操作員通知證實了攔截報告。 那個警告正是 身份驗證本應做的不便之事。 大約百分之十的中繼具有不同的容量，
3:57 未測量流量佔比。 Tor 路由和 SSH 伺服器身份各有職責。 在接受更改的主機金鑰並登錄之前，請通過 信任的通道驗證它。 回到您的應用程式，從正在運行的容器或虛擬環境開始。 找到它實際使用的 CA 捆綁包並應用相關的維護更新。
如何檢查已部署的修復程式？
4:12 重建並重新啟動已部署的進程，以便它可以加載已更改的信任 材料。在客戶端的真實環境中使用維護者的公共測試鏈條。 將憑證錯誤與網路逾時分開。 酒店 Wi-Fi 連接失敗是測試酒店 Wi-Fi 的絕佳方法。 這個微小的依賴是一個單獨捆綁的信任存儲， 例如 certifi。您的桌面瀏覽器從未在舊容器內部編輯該依賴項。 已部署的進程及其配置決定了修復程式是否到達。 那是驗證您的更新的地方。
4:42 如果您寧願閱讀而不是聽我說，那麼每天早上都會有差異報告免費發送到您的收件箱，網址是 thedailydiff.dev，連結如下。 所以今天的判決是「需要審核」。 在任何人結束此事件之前，我希望檢查已部署客戶端的信任。
什麼會得到「需要審核」的標記？
4:51 訂閱，點擊鈴鐺，並在評論中告訴我您是否會蓋上 不同的印章。這就是今天的差異。 我是Axrisi的Niko。 負責任地合併。 負責任地合併。 負責任地合併。
來源
- eMudhra Intermediate CA CompromiseDennis Jackson
- Private key compromise of eMudhra Intermediate CertificatesMozilla Bugzilla
- certifi 2026.10.19 releasecertifi
- Restore unaffected emSign rootscertifi
- Node 24.22.1 security releaseNode.js
- Update root certificates to NSS 3.131.1Node.js
- How I got over 300 Tor exit nodes removedKABA
- Security incident affecting some relay operatorsTor Project network health
