eMudhra中級CA洩露：瀏覽器黑名單和運行時信任差距
八個eMudhra中級簽章金鑰被洩露，其中六個用於TLS，兩個用於程式碼簽章。
八個eMudhra中級簽章金鑰被洩露，其中六個用於TLS，兩個用於程式碼簽章。此事件發生在Mozilla確認後，瀏覽器進行封鎖並發布了下游更新，以解釋為何已部署的應用程式需要檢查其自身的信任配置。一份獨立的Tor報告顯示，SSH主機身份警告正在發揮作用。
本影片重點
- 受損金鑰屬於中級簽章者。根憑證的不信任可以緩解整個鏈，而無需證明根私鑰已被洩露。
- 瀏覽器的緊急黑名單和應用程式捆綁的CA儲存庫可以遵循獨立的更新路徑。檢查運行中的程序及其實際信任配置。
- Mozilla獨立證實了可恢復的私鑰。報告沒有描述受影響中級憑證的CT條目；對其他客戶的實際濫用情況仍不明。
- 主要發布版本驗證了certifi 2026.10.19和Node 24.22.1，以適用於討論的分支。自訂CA捆綁包和其他運行時分支需要進行自己的檢查。
- Tor研究人員的333個中繼帳戶涉及10月初發布的事件，該事件於10月20日公開。大約百分之十是中繼數量，而不是攔截流量的測量。
- 單獨的網路逾時並不能證明憑證驗證拒絕了受損的鏈。保留驗證並區分傳輸錯誤和身份驗證失敗。
翻譯文字稿
譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。
為什麼固定的瀏覽器會讓應用程式暴露？
0:00 eMudhra瀏覽器修復聽起來像是一切就緒。 八個被洩露的簽章金鑰仍然會讓軟體留下過時的信任決策。 在這部影片中，誰可以簽名？ 為什麼客戶端會意見不合？ 以及哪個更新實際到達您的應用程式？ 一個微小的依賴項會保留自己的信任列表。 我們將回頭討論決定您的修復是否到達的過程。 今天是10月21日星期三，這是The Daily Diff。
0:22 eMudhra是一個憑證機構。 它簽署數位憑證，幫助軟體驗證網站和 服務。被洩露的金鑰包括六個用於網路連線，兩個用於 簽署軟體。中級憑證是受信任根憑證下的委託簽署者。 星期五，一位名叫Wayne的記者將證據送交給根程式。 到星期二，公開事件頁面正在解釋清理工作。 今天，開發人員會發現他們完美無缺的應用程式收集了多少份信任 正常的應用程式已收集。
中級金鑰授權了什麼？
0:49 這是普通的鏈。 一個網站提交一個憑證，一個中級憑證簽署它， 您的客戶端會追溯到它已經信任的根憑證。 根憑證是您的本地起點。 控制中級憑證私鑰的人可以在該授權下簽署。 一個數學上有效的簽名可能有一個完全不可信的簽署者。 驗證者需要一種在洩露後撤回信任的方法。 Wayne用每個金鑰簽署了訊息「我們這裡有問題，Wayne」。
1:12 用每個金鑰。 Mozilla驗證了金鑰控制，然後獨立恢復了金鑰。 緊急響應始於一個句子，聽起來像是有人注意到 辦公室印表機冒煙了。
哪些已證實，哪些仍不明？
1:22 公開報告稱，這些金鑰是錯誤生成的，並且可以從 去年四月創建的憑證中恢復。 對其他軟體的實際濫用情況仍然不明。 可恢復的簽署權限已經足夠緊急，無需捏造受害者名單。 這裡有一個重要的限制。 報告未發現那些中級憑證的憑證 那些中級憑證的透明度條目 在此期間。
1:42 它說，強制執行透明度的瀏覽器無法通過此途徑受到攻擊。 透過此途徑受到攻擊。該額外的瀏覽器檢查有助於解釋為何僅僅標題 誇大了實際情況。 eMudhra告訴Mozilla，大約有三萬個憑證需要遷移到 另一個鏈。這些是正常運作的服務，其所有者必須在清理期間更換憑證。 在清理期間。 某處，一份日曆邀請剛剛變成了一個生產依賴。
為什麼瀏覽器和運行時會產生分歧？
2:03 瀏覽器供應商分發緊急黑名單。 報告記錄了Firefox和Chrome在星期五的行動， 隨後是Apple和Microsoft。 這些客戶端可以拒絕受損的中級憑證，同時識別其 根憑證。該規則獨立於您的應用程式捆綁包傳播。 某些客戶端會對照受信任的根憑證檢查憑證鏈，而無需使用緊急 撤銷資訊。授權單位可以發布撤銷， 並且該客戶端可以繼續接受該憑證鏈。
2:27 當訪客閱讀標誌時，在門上貼標誌效果更好。 Mozilla表示，某些Android個人資料未能應用更新的黑名單， 在啟動時。Firefox 158.02中發布了一個修復程式。 因此，也要保持瀏覽器更新。 公告無法盤點您的手機。 當客戶端缺乏更窄的阻止功能時，維護者可以移除信任錨點。 Mozilla的討論串描述了對emSign ECC根憑證的緊急不信任， 第三代。從信任儲存中移除根憑證會阻止依賴該根憑證的鏈，
2:54 即使該根憑證的私鑰本身從未被洩露。 Python最新的certifi版本是一個下游更新。
哪些更新到達了Python和Node？
3:01 它的提交還在早先移除後恢復了未受影響的emSign根憑證。 刪除所有帶有公司名稱的東西是維護包的糟糕替代品。 您希望危險的鏈被拒絕，而合法的客戶仍然可以運作。 客戶仍然可以運作。 發布歷史記錄保留了這兩個決定。 安全清理工作光鮮亮麗，因為它緊急 精確，並因為午餐期間任何服務中斷而受到指責。 Node版本24.22.1今天發布，更新了
3:26 根憑證。檢查您自己的分支建議和實際的CA配置。 自訂捆綁包可以改變程序使用的信任儲存。 在Tor中，一位研究人員昨天發表了一份報告，涉及三百三十
Tor主機金鑰警告捕獲了什麼？
3:36 三個被洩露的出口中繼。 這次攔截始於本月初。 這些中繼在幾天後被標記並關閉，然後報告才發布。 SSH警告研究人員伺服器身份已更改。 他向Tor的網路健康團隊報告了此事。 他們的操作員通知證實了攔截報告。 那個警告正在做 認證本應做的不便之事。
3:57 大約百分之十的中繼具有不同的容量， 導致流量份額未測量。 Tor路由和SSH伺服器身份有獨立的職責。 在接受並登錄之前，請透過 信任的通道驗證已更改的主機金鑰。 回到您的應用程式，從運行中的容器或虛擬環境開始。
如何檢查已部署的修復程式？
4:12 找到它實際使用的CA捆綁包，並應用相關的維護更新。 重建並重新啟動已部署的程序，以便它可以載入已更改的信任 材料。在客戶端的真實環境中使用維護者的公共測試鏈。 環境。將憑證錯誤與網路逾時分開。 飯店Wi-Fi上的連線失敗是飯店Wi-Fi的絕佳測試。 這個微小的依賴項是一個獨立捆綁的信任儲存， 像是certifi。您的桌面瀏覽器從未在舊容器內編輯該依賴項。 容器。已部署的程序及其配置決定了修復程式是否
4:42 到達了。那是驗證您的更新的地方。 如果您寧願閱讀而不是聽我說，那麼diff會每天早上免費 發送到您的收件箱，網址是thedailydiff.dev，連結如下。
什麼會獲得「NEEDS REVIEW」印章？
4:51 所以今天的判決是NEEDS REVIEW。 我希望在任何人關閉此事件之前檢查已部署客戶端的信任。 訂閱，點擊鈴鐺，並在評論中告訴我您是否會給它不同的 蓋章。這就是今天的diff。 我是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
