📡 Signal｜Teku と Besu、eMudhra の認証局を信頼しない Docker 版を公開

Ethereum のコンセンサスクライアント Teku と実行クライアント Besu は、インドの認証局 eMudhra 系のルート証明書を信頼しない Docker イメージを公開した。Besu 26.10.2 が10月26日、Teku 26.10.3 が27日 (いずれも協定世界時) に出ている。

Teku: eMudhra 証明書に関するセキュリティ告知 (2026-10-28 更新・既定の mainnet ノードは影響なし、悪用の報告なし)HackMD

既定の設定で mainnet を動かすノードは影響を受けない。危なかったのは、外部署名器など HTTPS で外とつながる設定を持つバリデータで、通信を横取りできる攻撃者に接続先を偽装される余地があった。悪用の報告は出ていない。

発端は eMudhra の中間証明書の秘密鍵

Mozilla の課題管理 (Bugzilla) には10月18日、「eMudhra: 中間証明書の秘密鍵の漏えい」という件名の報告が立った。Mozilla は自分で鍵を復元できたとし、鍵の生成手順に欠陥があって悪用は容易だと書いている。対象の中間証明書は 8 枚 (TLS 用 6 枚・コード署名用 2 枚) で、Firefox は失効リスト OneCRL で信頼を止めた。

中間証明書の秘密鍵が漏れると、攻撃者はどのサイトの名前でも本物に見える証明書を作れる。Go 言語は10月19日の Go 1.27.3 で、これらの中間証明書を含む証明書の鎖を通さないよう検証部品を改めた。

Java には別の事情があった。Teku の告知は「Java は既定で失効を確認しない」と書く。そのため Java の実行環境は、それぞれに修正が要る。Teku の Docker イメージ (consensys/teku) は 26.10.2 までのすべての版が、eMudhra 系の emSign ECC Root CA - G3 というルート証明書を信頼したままだった。ルートを信頼している限り、漏れた中間証明書の下で作られた偽の証明書も検証を通る。

危ないのは HTTPS の接続先を持つバリデータ

Teku の告知によると、影響があるのは HTTPS の接続先を使う設定だけだ。外部署名器、別に立てたビーコンノード、提案者設定の URL、ブロックビルダーやリレー、別に立てた実行クライアント、チェックポイント同期の URL、メトリクスの送り先がそれにあたる。テストネットの Sepolia・Hoodi・Ephemery では、空のデータベースから起動すると該当する。

最悪の場合として告知が挙げるのは 2 つだ。外部署名器になりすまされると、取り消せない自発的退出 (voluntary exit) と、手数料の受け取り先を書き換えるビルダー登録に署名させられうる。偽のビーコンノードにつながれると、手数料が攻撃者に入るブロックを提案させられうる。告知は外部署名器を最も危険度の高い接続先としている。

Besu では向きが逆になる。Besu の障害報告によると、--rpc-http-tls-ca-clients-enabled を有効にしたノードでは、攻撃者が自分でクライアント証明書を作り、通信を横取りせずに直接つなげる。報告はこれを最も深刻なケースとしている。

Docker の外で動かす運用者は Java を自分で更新する

今回の修正は Docker イメージに限られる。Besu のリリースノートは、配布アーカイブ (tar/zip) で動かしている場合、その JDK がまだ eMudhra 系のルートを信頼しているかもしれないと注意している。Teku も、Docker を使わない利用者には自分で Java を更新するよう求める。

Teku の告知は、Java 26 は保守が終わっているとして Java 25 への移行を勧め、Docker 利用者には consensys/teku:26.10.2-jdk25 への切り替えを案内している。そのうえで、外部署名器の信頼ストアを固定すること、相互 TLS を使うこと、起動時のデータはネット越しでなく手元のファイルから読むことを勧めた。26.10.3 のリリースノートは、土台にしている Eclipse Temurin のベースイメージにはまだ修正が入っていないとも書いている。

同じ eMudhra の件で、Bitcoin の側では10月22日、Lightning Labs が Taproot Assets や Lightning Terminal を Go 1.27.3 で作り直した版を出している (10月23日の記事)。Go で書かれたソフトは実行ファイルの作り直しで、Java で書かれた Ethereum のクライアントは実行環境の信頼ストアの差し替えで直す。一つの認証局の事故が、言語ごとに違う修理の手順を求めた。

次に見るもの

確認先は Teku のセキュリティ告知のページだ。10月28日に更新されたが、本文はまだ「今後のリリースを待つように」と書いたままで、26.10.3 に触れていない。Eclipse Temurin のベースイメージに修正が入り、次の Teku のリリースノートが Docker 以外の利用者への手当てをどこまで書くかで、運用者が自分で直す範囲が決まる。

ことば

外部署名器 — バリデータの署名鍵をノード本体から切り離して持ち、ネット越しに署名だけを返す仕組み。鍵を守るために使われるが、つなぎ先を偽装されると、偽の相手に署名を求められる入口にもなる。
ルート証明書と中間証明書 — 認証局はルート証明書を頂点に、中間証明書で実際のサイト証明書に署名する。中間証明書の秘密鍵が漏れると、上のルートを信頼する環境ではどの名前の偽証明書も本物として通る。
自発的退出 (voluntary exit) — バリデータが自分でステーキングの仕事を降りる手続き。いったん実行すると取り消せないため、偽の署名器に署名させられる危険の中で最も重い部類に入る。

🔗 一次ソース

発端は eMudhra の中間証明書の秘密鍵

危ないのは HTTPS の接続先を持つバリデータ

Docker の外で動かす運用者は Java を自分で更新する

次に見るもの

ことば

関連記事