Cloudflare、eMudhraの弱い鍵を追跡：約2万2000件の握手試行、自社接続の傍受を示す証拠なし

Cloudflareは2026年10月30日、10月に公表したeMudhra認証局の問題について追報を出した。影響を受けた八つの中間署名鍵は極端に弱く、公開証明書から誰でも秘密鍵を復元できたという。例として一つの秘密値は、予測困難な115桁の数ではなく、単に4だった。今回の追報では、偽造証明書、試みられたTLSハンドシェイク、実証された通信の傍受を区別する必要がある。記事名の「4 real?」は問いかけであり、実際の攻撃が四件確認されたという意味ではない。

Cloudflareによると、自社の影響が大きいシステムの修正は10月19日に始まった。顧客のオリジンへの外向き接続の多くを担うPingoraは、弱い鍵による証明書チェーンを拒むよう数時間で修正された。AIを使ったコード分析で他の信頼経路も四時間以内に洗い出し、各担当者が影響を確認して対応した。記事時点で優先度の高い自社システムはすべて修正済みだが、影響の小さい確認済みチケットは少数残っていた。この記述はCloudflare内部の進捗であり、インターネット上の全クライアントが更新済みという証拠ではない。

Pingoraでのログ収集は10月21日に展開を終えた。その後約一週間で、弱いeMudhra鍵を使ったハンドシェイクの試行を約2万2000件観測した。約三分の二は、Cloudflare自身が前の記事で紹介した試験サイトへのアクセスだった。残りのほぼすべては、オリジンサーバーが自ら設定したように見える証明書によるものだった。証明書の検証を設定していた試行は、修正済みシステムですべて拒否された。この数字は試行回数であり、被害者数、固有のサイト数、成功した攻撃件数ではない。

約160件では、偽造証明書のSANに別組織のドメインが載り、接続時のSNIと一致しなかった。公開後に作られ、有効期間が公開認証局の許容範囲を超える証明書もあった。Cloudflareは、これらが通信路で差し込まれたものより、サーバー自身のデフォルト証明書らしいと説明する。名前の不一致はホスト名検証に失敗し、同じサーバーが複数のCloudflare拠点に同一証明書を返していたためだ。一枚の偽造証明書の日付は10月20日18時19分UTCで、Mozillaの公開報告から一時間未満だった。偽造の早さは示すが、自社の接続が傍受された証拠はないとしており、標的を絞った傍受の可能性までは排除していない。

利用者側がなお問題の証明書チェーンを信頼するか調べるため、Cloudflareは一部のチャレンジページから二つの接続先へ探査し、一週間に約5000万回の探査を得た。ただし、JavaScriptを実行してチャレンジページに来た端末だけが対象で、未確認のボットも多い偏った標本である。全インターネット利用者の代表調査ではない。途中で対照側の証明書、証明書透明性のタイムスタンプ、G3クロス署名、ルートチェーンが変更された。無関係なロールバックで観測が途切れ、10月27日に再開し、対象比率も適格ページの1%から10%へ上がった。グラフの段差をそのまま修正の効果とは読めない。

この限定された標本では、新しい主流ブラウザーの多くは修正済みだが、古いブラウザー、ボット、組み込みブラウザーは遅れているとCloudflareは述べる。Android WebViewの探査では約30〜40%がまだ問題のチェーンを受け入れた。大規模ネットワーク別の図では探査の半数超が受け入れたものの、その比率を全利用者に外挿できない。10月29日のmacOS版Chrome 150〜154を名乗るボットの分類変更も、一方のグラフを修正が進んだように見せた。Linuxの同じ世代での低下は修正と整合するが、変動する標本から全体の因果効果は測れない。Cloudflareは関連製品と信頼ストアの更新、迅速な失効の仕組みを促している。