Proxyman 26.3.0、侵害された eMudhra 証明書のサーバーをブロック

4 分で読めます

macOS 版 Proxyman 26.3.0 で、侵害された eMudhra 証明書を使うサーバーをブロックするようになりました 🔒

先週、eMudhra の中間証明書 8 件の秘密鍵が漏えいしました。ブラウザや OS は数日以内にこれらの証明書を信頼しなくなりました。しかし、Proxyman を経由して通信しているアプリは、その保護を受けられていませんでした。今回のリリースで、この問題に対応しました。

このブログでは、次の内容を解説します：

• eMudhra で何が起きたのか。
• Proxyman を経由した通信がなぜ影響を受けていたのか。
• Proxyman 26.3.0 でどう修正されたのか。
• 修正を自分で確かめる方法。

1. 何が起きたのか？

eMudhra は認証局 (Certificate Authority、CA) です。CA は、Web サイトが本物であることを証明する証明書に署名します。ブラウザは、信頼された CA が署名した証明書を持つ Web サイトを信頼します。

2026 年 10 月 20 日、あるセキュリティ研究者が、eMudhra の中間証明書 8 件の秘密鍵が誤って生成されていたことを公表しました。公開されている証明書から、誰でもこれらの鍵を復元できます。

これらの鍵のどれか 1 つがあれば、攻撃者は銀行や企業の API など、任意の Web サイトの証明書を偽造できます。eMudhra を信頼しているアプリは、それを本物として受け入れてしまいます。

対応は迅速でした：

• Chrome と Firefox が 8 件の証明書をブロックしました。Microsoft と Apple も数日後に続きました。
• eMudhra がこれらの証明書を失効させ、Sectigo も自社が署名した複製の証明書を失効させました。

そのため、最新のブラウザや OS を使っていれば保護されています。ただし、1 つだけ穴がありました。それがプロキシです。

2. Proxyman を経由した通信がなぜ影響を受けていたのか

Proxyman はアプリとサーバーの間に入ります。HTTPS の通信を表示するため、2 つの接続を行います：

1. アプリ → Proxyman: アプリは、Proxyman が作成した証明書を見ます。その証明書は、インストールして信頼した Proxyman CA が署名したものです。
2. Proxyman → サーバー: Proxyman は、サーバーの本物の証明書を受け取ります。

2 つ目の接続では、Proxyman はどんな証明書も受け入れていました。これは意図的な設計です。ローカルやステージング環境のサーバーを自己署名証明書でデバッグすることはよくあり、Proxyman がその作業の邪魔をすべきではないからです。

ただし問題がありました。アプリはサーバーの本物の証明書を見ることがありません。 見えるのは Proxyman の証明書だけです。そのため、Apple、Google、Microsoft が eMudhra の証明書をブロックした後も、それを使うサーバーへのリクエストは Proxyman 経由で通ってしまっていました。

あるチームが issue #2797 でこの問題を報告しました。そのチームの会社は、漏えいした証明書に対する対策を講じていました。誰かが Proxyman を起動したまま停止し忘れると、本人が気づかないうちにその対策をすり抜けてしまいます。報告とリスクの説明をありがとうございます 🙏

3. Proxyman 26.3.0 での修正

まず、Proxyman が使う TLS ライブラリ (SwiftNIO SSL) に修正がないか確認しました。ありませんでした。また、Proxyman は証明書の検証を意図的にスキップしているため、ライブラリを更新しても解決しません。そこで、当社側で修正しました。

Proxyman 26.3.0 には、侵害された eMudhra 証明書 8 件の組み込みブロックリストがあります。ブロックリストには、Sectigo が署名した複製も含まれます。SSL Proxying で HTTPS や WebSocket (WSS) の通信を復号するとき、Proxyman はすべてのサーバーの証明書チェーンを確認します：

• チェーン内のいずれかの証明書が漏えいした鍵を使っている場合、Proxyman は接続を閉じます。
• サーバーが自分の証明書だけを送ってくる場合、Proxyman はその証明書の署名者を確認します。漏えいした鍵で署名されていれば、Proxyman は同様に接続を閉じます。
• それ以外のサーバーは、何も変わりません。

このチェックは、Proxyman がサーバーに接続するときに 1 回だけ実行され、非常に高速です。

Proxyman がサーバーをブロックすると、アプリは理由を示す 502 Bad Gateway を受け取ります。その内容は次のステップで確認できます。

4. 自分で試す

研究者は、漏えいした証明書を使うテストサーバーを運用しています。そのうち 1 つを使えば、環境を確認できます：

1. ダウンロードページ、または Proxyman → Check for Updates… から Proxyman 26.3.0 にアップデートします。
2. dv-g3b-emudhra.we-have-a-problem.com で SSL Proxying を有効にします。
3. Proxyman 経由でリクエストを送信します。Proxyman はデフォルトでポート 9090 で動作します：

curl --proxy http://localhost:9090 https://dv-g3b-emudhra.we-have-a-problem.com/

次のような結果になります：

Bad Gateway: Blocked dv-g3b-emudhra.we-have-a-problem.com:443 because its certificate chain uses a compromised eMudhra CA key

https://github.com/ を指定して同じコマンドを実行してみてください。これまでどおり動作します。

5. 知っておくと良いこと

• Windows と Linux: Proxyman の Windows 版と Linux 版にも、今週中に同じ修正が提供されます。
• 自己署名証明書は引き続き使えます。 Proxyman がブロックするのは、漏えいした eMudhra 証明書だけです。ローカルやステージング環境のサーバーは、これまでどおり動作します。
• Proxyman はデバッグツールです。 会社のセキュリティチェックの代わりにはなりません。デバッグが終わったら、Proxyman を終了するか、システムプロキシをオフにしてください。

関連情報

• eMudhra Intermediate CA Compromise: 詳細と、影響を受ける証明書の一覧
• eMudhra によるインシデントの声明
• GitHub issue #2797
• SSL Proxying のドキュメント
• Proxyman の変更履歴