Ing. Calogero Bono
Cloudflareは、2026年10月19日に発見されたインドの認証局eMudhraの8つの弱い暗号鍵について、フォローアップの分析を公表しました。同社によれば、最も重要なシステムはすでに保護されており、接続が傍受された形跡もないとしています。しかし偽の証明書は数時間のうちに現れ、多くのブラウザ、ボット、埋め込みアプリが、侵害された証明書チェーンを今も受け入れています。サイトやオンラインサービスを運営する人にとって、このリスクは理論上の話ではありません。
事実に入る前に、いくつかの用語を確認します。 CA（認証局）は、HTTPSの鍵マークの根拠となる証明書を発行する機関です。中間鍵は、CAがサイトの証明書に署名するために使う鍵です。CRLは失効した証明書の一覧です。Certificate Transparencyは発行された証明書の公開登録簿で、SCTはその受領証にあたります。SANとSNIは、証明書に含まれるドメイン名と、クライアントが要求したドメイン名を示します。
eMudhraの鍵に何が起きたのか？
Cloudflareによると、eMudhraは鍵を保護するために115桁の数値を選ぶべきでしたが、数値4を使いました。他の7つの鍵も同じく弱く、56、66、115、155、156、230、237といった値でした。
Cloudflareは、中間鍵は公開された証明書から誰でもほぼすぐに再構築できると説明しています。そのため誰でも任意のドメインの証明書を作成でき、更新されておらずCertificate Transparencyのチェックもないクライアントはそれを受け入れてしまいます。
同社によれば、今回のケースは前例がありません。DigiNotar、TÜRKTRUST、TrustWaveといった事件では、偽の証明書を発行する権限を得たのはごく一部の主体だけでした。
Cloudflareはどう対応したか？
10月19日、影響の大きいシステムへのパッチ適用が始まりました。まずは顧客サーバー向けに、接続の大部分を扱うPingoraプロキシから着手しました。数時間のうちに、脆弱な鍵の拒否を開始しています。
並行して、AIを利用したコード分析により、これらの鍵を信頼していた他のシステムを4時間で特定しました。それぞれについてチケットを起票し、緊急の対応は直ちに、その他は前週末までに行う計画でした。公表時点では、影響の小さいチケットが数件残っています。
鍵はすでに証明書の偽造に使われたのか？
Cloudflareによれば、そうです。10月21日以降、Pingoraのログが弱い鍵で署名された証明書を記録しています。約1週間で、約22,000回のハンドシェイクの試行を確認しました。その3分の2はテスト用サイトへのもので、残りのほぼすべては、弱い中間鍵で自ら証明書を作ったように見えるサーバーへのものでした。有効な検証を伴うハンドシェイクはすべて拒否されています。
約160件は異常で、他の組織のドメイン名を含み、そのうちのいくつかは消費者向けIoT機器に関連していました。一部の証明書は2年以上有効で、公的CAが発行できる期間を超えていました。ある証明書は10月20日18時19分（UTC）のもので、Mozillaが報告を公開してから1時間も経っていませんでした。
ただし、Cloudflareはこれらが傍受の試みではなく、サーバーのデフォルト証明書である可能性が高いと見ています。脆弱性が公表直後に探査されるのは、Oracle E-Business Suiteの事例と似ています。
まだ脆弱な訪問者はどれくらいいるのか？
Cloudflareは接続を切断せずに訪問者を直接テストすることはできません。そこで、検証ページに2つのプローブを追加しました。1つはeMudhraの証明書を使うもの、もう1つは対照用です。1週間で5,000万件のプローブを収集しました。
同社が描く状況は次のとおりです。
- 最新の更新済みブラウザはおおむね保護されています。
- ボットや古いブラウザは保護されていません。
- Android WebViewのような埋め込みブラウザを使うアプリは、30〜40%でチェーンを受け入れています。
- 大規模ネットワークでは、プローブの半数以上が侵害されたチェーンを受け入れています。
最初の週末に若干の改善が見られましたが、その後は横ばいです。ただし、トラフィックは確認されていないボットによって偏っており、JavaScriptを実行するクライアントだけがプローブを送信しています。
知っておくべき限界
eMudhraは鍵生成スクリプトのエラーを認めていますが、まだ公開していません。監査人やクロス署名者の役割、そしてCRLが一度は正しい可能性のある鍵で、その後に弱い鍵で署名された理由も不明なままです。Cloudflareは間接的な兆候に基づいて傍受を否定していますが、標的を絞った傍受を排除できるわけではありません。さらに、訪問者のデータはボットによって歪められています。
デジタル分野で働く人にとっての変化
サイト、アプリ、業務システムを運用しているなら、サーバー、ライブラリ、クライアントがeMudhraの鍵を拒否するよう設定されているか確認してください。外部サービスに接続するソフトウェア、たとえWebViewを使うモバイルアプリや自動化スクリプトも対象で、更新が遅れがちです。macOSで開発している場合は、Cloudflareが示す手順に特に注意してください。セキュリティ更新を管理してくれるホスティングを利用しているなら、パッチの状況を提供会社に確認しましょう。この問題は、証明書を電子署名に使っている人にも関係します。
私たちの見解
最も憂慮すべき点はバグそのものではなく、更新の遅さです。誰でも再構築できる鍵は重大な欠陥ですが、プローブの半数以上が今もチェーンを受け入れているという事実は、誰も更新しないソフトウェアというより大きな問題を示しています。Cisco SD-WAN上のマルウェアKeyDriftの事例でも、暗号鍵の重要性が浮き彫りになりました。また、監査とクロス署名がいずれも問題を止められなかったことから、管理体制への疑問も残ります。
よくある質問
eMudhraの弱い鍵とは何ですか？
CAの8つの中間鍵で、4や56のような小さな数値から生成されていました。そのため、誰でも公開された証明書から再構築でき、偽の証明書に署名できてしまいます。
Cloudflareは侵害されましたか？
Cloudflareによれば、同社の接続が傍受された証拠はありません。優先度の高いシステムは更新済みで、影響の小さいチケットが数件残っているだけです。
サイトやアプリにはどの程度のリスクがありますか？
クライアントによって異なります。更新されておらず、Certificate Transparencyのチェックも行わないクライアントは、どのドメインに対する偽の証明書も受け入れる可能性があり、傍受につながるおそれがあります。
どのソフトウェアが最も危険に晒されていますか？
ボット、古いブラウザ、そしてAndroid WebViewのような埋め込みブラウザです。Cloudflareによれば、後者では30〜40%が今も侵害されたチェーンを受け入れています。
今すぐ何をすべきですか？
システムを更新し、Cloudflareが挙げたDennis Jackson氏のサイトの指示に従ってください。macOSで開発している場合は、その指示を優先してください。
eMudhra問題の今後数週間で注目すべき点
この問題は二つの面で進行中です。eMudhraによる説明と、更新のペースです。両方を追い続けることをお勧めします。
- eMudhraが鍵生成スクリプトと、監査およびクロス署名者に関する結論を公開するか確認してください。
- アプリで使うブラウザやランタイム、特にWebViewの更新情報を追ってください。
- サーバーのログで、要求したドメイン名と一致しない証明書がないか確認してください。
