跳到正文
Hacker News 熱門（buzzing.cc 中文翻譯）·· 4 小時前精選AI 評分88

eMudhra 八個中繼 CA 私鑰只有 8 位元，數毫秒即可破解

八位信任；eMudhra的CA密钥在几毫秒内被破解

AI 導讀

eMudhra 8 個中繼 CA 的私鑰只有一個位元組，Scott Helme 從公開憑證還原出私鑰，每把最多隻需測試 255 個值。Chrome 和 Firefox 已封鎖相關中繼憑證，但多數非瀏覽器 TLS 用戶端預設不檢查撤銷狀態或憑證透明度（CT），因此可能接受偽造憑證。文章建議更新作業系統及軟件所用的 CA 憑證庫；無法更新的裝置可能信任相關憑證至 2039 年 7 月。

推薦理由

文章由弱私鑰推演至憑證偽造風險，並比較瀏覽器與非瀏覽器 TLS 用戶端的撤銷檢查差異，説明更新 CA 憑證庫的重要性。

正文 · 繁體中文

eMudhra 其中一把憑證授權機構的私鑰，數值竟然是 4。

不是以 4 開頭的數字，也不是 4 後面接着幾百個隨機數字，而是單純的 4……另一把是 56，還有一把是 115。我知道這些數值，因為我剛才就在自己的手提電腦上，從它們的公開憑證中還原出所有私鑰，整個過程不到一秒。

發生了甚麼事

10月17日星期六，一名安全研究人員向 Apple、Google、Microsoft、Mozilla 和 eMudhra 報告，eMudhra 八張中間憑證的私鑰已遭洩露。當晚，Chrome 推送 CRLSet 更新，封鎖這些憑證；幾小時後，Mozilla 透過 OneCRL 在 Firefox 封鎖了它們。星期二 20 日，Mozilla 公開宣佈此事，並推出 NSS 更新以移除 eMudhra 根憑證；Chrome 則確認該根憑證將納入 Chrome Root Store v43。

這八張中間憑證包括六個 TLS 憑證簽發 CA（DV、OV 和 EV，各有兩代）以及兩個程式碼簽署 CA，全部於 2025 年 4 月建立。每一張憑證也都在 2025 年 5 月由 Sectigo 的 AAA Certificate Services 根憑證交叉簽署。

這就是「是甚麼」，但有趣的是「如何發生」，Ian Carroll 在討論串中用一句話概括了這件事：

它們本質上是極弱的單位元組金鑰，任何人都能破解，而且問題無法遏止。

私鑰實際上是甚麼

這些是使用 P-384 曲線的橢圓曲線金鑰。私鑰只是一個數字：d。公開金鑰，也就是放進憑證、供所有人查看的內容，是 d × G；其中 G 是曲線上所有人共用的一個固定點，而「×」代表按照該曲線的特殊運算方式，將 G 與自身相加 d 次。

正向運算很容易，但反過來由公開金鑰推算出 d，則被認為難以實際做到。整個安全模型就是如此，而要成立，d 必須非常大。P-384 私鑰應該是一個隨機的 384 位元數字，提供 2³⁸⁴ 種可能（約為 10¹¹⁵），因此根本沒有人會逐一搜尋。

eMudhra 的金鑰看起來是這樣：

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

P-384 私鑰應該是這樣：

d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34

這是 47 個零位元組，後面接着一個位元組，而且八把金鑰全都是如此。一個位元組有 256 種可能，因此「搜尋」方法就是計算 1 × G、2 × G、3 × G，直到結果與憑證相符為止，最多隻需 255 次。

所以，整件事——這些 CA 能簽發的每一張憑證，以及每個信任它們的用戶端——都只建基於八個位元。

我查證了

Mozilla 在公告中附上受影響的憑證，因此我取回全部 16 張（8 把金鑰，各自用於兩張已簽發的憑證：一張由 eMudhra 簽發，另一張由 Sectigo 簽發），並以暴力方式破解。每一把都瞬間被破解；六個 TLS 數值和兩把程式碼簽署金鑰同樣脆弱：

中間憑證 類型 d
EM DV TLS CA - G3B TLS 156
EM DV TLS CA - G3C TLS 230
EM EV TLS CA - G3B TLS 115
EM EV TLS CA - G3C TLS 56
EM OV TLS CA - G3B TLS 155
EM OV TLS CA - G3C TLS 4
EM OV CS CA - G3B 程式碼簽署 66
EM OV CS CA - G3C 程式碼簽署 237

值得注意的是，這些憑證看起來完全沒有問題。由 d = 4 推導出的公開金鑰，是曲線上一個完全有效的點；編碼沒有問題，曲線也沒有問題，每項結構檢查都能通過。找出問題的唯一方法，就是實際嘗試。

為甚麼「無法遏止」

一般而言，CA 金鑰遭到入侵，代表有人把它偷走了！有竊賊，有事情發生的時間點，而你至少可以推斷現在誰能存取該金鑰。

這裏，沒有人需要偷取任何東西。從憑證存在的那一天起，密鑰實際上就已公開。自 2025 年 4 月以來，任何人在任何時候查看這些憑證，都能在一般硬件上於數毫秒內還原出密鑰。這段窗口期長達 17 個月，而且無從得知是否有人曾這樣做。

Chrome 指出，由於 Chrome 強制執行 Certificate Transparency（CT），而沒有任何鏈結至這些 CA 的 TLS 憑證曾出現在 CT 中，因此 Chrome 預設不會信任任何偽造憑證。這一點屬實，對瀏覽器而言也令人安心。不過，CT 只能偵測錯誤簽發，不能阻止錯誤簽發，而且很多軟件完全不會檢查 CT。

現時哪些對象面臨風險

主流且已更新的瀏覽器很可能完全不受影響。Chrome 和 Firefox 會直接封鎖這些中介憑證，而且兩者都要求憑證符合 CT；Safari 也要求符合 CT。

其他情況則截然不同。大多數非瀏覽器 TLS 用戶端（也就是預設設定下幾乎所有其他軟件），例如 curl、Python、Node、Go、Java、git、套件管理程式，以及你使用的所有指令碼和常駐程式，都有三個在此很關鍵的特點：它們信任磁碟上的 CA 憑證套件、預設不檢查憑證吊銷狀態，也不檢查 CT。因此，eMudhra 和 Sectigo 吊銷這些中介憑證，對它們完全沒有幫助。我談到 TLS 和 PKI 時，經常會發現人們忽略了用戶端生態系統的規模有多龐大。在培訓中，我們經常會討論 CRLite 等現代吊銷狀態解決方案；它在桌面瀏覽器上效果出色，對其他 TLS 用戶端卻毫無作用。不妨想想現在有哪些東西需要更新其根憑證庫，而以下還只是冰山一角：

  • curl | sh 安裝程式及自動更新程式。許多工具會透過 HTTPS 下載指令碼或二進制檔來安裝或更新，卻不檢查簽章（例如 rustup、nvm、Homebrew 的安裝程式、無數個「install.sh」網頁，以及物聯網韌體更新程式）。這裏若出現偽造憑證，就可能導致執行攻擊者的程式碼，而且通常會以 root 權限執行。
  • CI/CD 管道。GitHub/GitLab runners、Jenkins 和建置容器會擷取依賴項及推送構件，同時持有雲端金鑰、登錄檔權杖和簽署金鑰。它們在過時的基礎映像和共享網絡上執行，而底層全都依賴 curl、Python、Go 和 Node。
  • 伺服器對伺服器 API 呼叫。付款服務供應商、webhook、OAuth 權杖交換和雲端 SDK（AWS CLI 和 boto 使用各自的 certifi 憑證套件；Terraform 和 kubectl 使用 Go）都涉及這類呼叫。這些呼叫會在標頭中傳送 API 密鑰及客戶資料。
  • 物聯網、嵌入式及 OT 裝置。攝影機、路由器、汽車、醫療裝置、智能家電、支付終端機和工業控制器都會連線至伺服器，以接收指令和更新。它們的憑證套件會一直維持不變，直至 2039 年；這正是「無法遏止」的問題成為現實的例子。
  • Windows 程式碼簽署。這與 TLS 無關，但漏洞相同：Windows 會直接信任 eMudhra CS 根憑證。以 EM OV CS CA - G3B/G3C 簽署的惡意軟件，對任何不檢查憑證吊銷狀態的系統而言，看起來就像由真正發行者簽署的軟件。

我在自己的裝置上用本機伺服器和一張適用於 api.stripe.com 的憑證進行測試；這個名稱的價值之高，相信大家都會認同。使用預設設定時，curl 顯示 SSL certificate verify ok，Python 則完成了交握，而 Node 顯示 authorized: true。我測試過的每部 Linux 和 macOS 裝置都是如此。在 Windows 上，CryptoAPI 會接受該憑證鏈，除非啟用了撤銷檢查；即使啟用了，也只有兩條驗證路徑中的一條顯示憑證已撤銷。

scott@Middle-Earth:~$ curl -v --resolve api.stripe.com:18888:127.0.0.1 https://api.stripe.com:18888/
* Added api.stripe.com:18888:127.0.0.1 to DNS cache
* Hostname api.stripe.com was found in DNS cache
*   Trying 127.0.0.1:18888...
...snip...
* Server certificate:
*  subject: CN=api.stripe.com
*  start date: Oct 20 18:39:57 2026 GMT
*  expire date: Oct 21 18:44:57 2026 GMT
*  subjectAltName: host "api.stripe.com" matched cert's "api.stripe.com"
*  issuer: C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: api.stripe.com:18888
> User-Agent: curl/7.68.0
> Accept: */*
>
...snip...
< HTTP/1.0 200 ok
< Content-type: text/html
<
<HTML><BODY BGCOLOR="#ffffff">
<pre>
s_server -accept 127.0.0.1:18888 -cert /tmp/tmp.rBcIpjTbZV/leaf.pem -key /tmp/tmp.rBcIpjTbZV/leaf.key -cert_chain /home/scott/code/test/intermediate-sectigo.pem -www -quiet
...snip...
</pre></BODY></HTML>
...snip...
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
scott@Middle-Earth:~$

你可以在該憑證中填入任何其他主機名稱，便具備攔截該裝置流量所需的一切；你只需進入網絡傳輸路徑。

你現在應該怎樣做

幸好，對於可以更新的裝置，所需步驟並不特別複雜，建議歸根究柢就是「更新它們」。問題在於那些無法更新或不容易更新的裝置。

  1. 更新所有隨附 CA 套件的軟件：你的 OS ca-certificates 套件、certifi、Node、Homebrew；待基礎映像納入變更後，重新建置容器映像。
  2. 無法更新的裝置才是棘手之處。路由器、打印機、電視，以及韌體已凍結的家電，都會信任這些憑證，直至憑證到期；到期日是 2039 年 7 月……

八個位元。整整 17 個月，這就是大量非瀏覽器軟件與一張可用於任何網站的偽造憑證之間的全部防線；這張憑證會破壞你所有加密流量的安全性。

來源

MDSP 討論串：https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ

研究公告：https://emudhra.we-have-a-problem.com/

更新於 2026年10月20日 20:16 UTC
文章發佈後不久，Mozilla 公開了事故工單：https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

eMudhra 已在該工單中交代事件經過。看來，儀式期間使用的腳本有錯誤，導致在 HSM 上建立了第二組較弱的金鑰，而由於名稱相近，人為失誤令 CSR 使用了錯誤的金鑰。這些新資訊沒有令我上文的文章內容有任何改動。我亦可以確認，只需向 AI Agent 輸入一個簡單提示詞，我便能找回 CA 的私密金鑰。Claude 只用一個提示詞便能找回私密金鑰。


你喜歡這篇文章，或覺得內容有用嗎？
☕️ 歡迎請我喝杯咖啡以示感謝！
🔔 訂閲免費通知，在我發佈文章時接收通知！
🤩 成為會員，支持我的內容！

標籤：憑證授權機構、憑證撤銷

來源：Hacker News 熱門（buzzing.cc 中文翻譯） · scotthelme.co.uk

#教學/實踐