🔐

ECH時代のインターネット検閲とその運用的課題

に公開

以前SNIや検閲について以下の記事を書きました。

https://catatsuy.medium.com/政府によるインターネットの検閲とsniについて-5339da2fad7c

この記事はその続編としてEncrypted Client Hello (ECH)の現状と展望を整理します。何か誤りがあれば教えてもらえると非常にうれしいです。

ESNIからECHへ

以前の記事では韓国政府によりESNIがブロッキングされたことを紹介していましたが、その後に中国政府からもESNIがブロックされました。これによりESNIの標準化が事実上中止され、その後ECHの標準化作業が開始されました。

ESNIの問題点はESNIを利用していることが検閲側から分かってしまうことでした。そこでClientHello全体を暗号化し、既存のClientHello (Outer)にダミー拡張を加え、真のClientHello (Inner)を暗号化して送信する仕様に進化しました。

ブラウザ側はencrypted_client_hello拡張を常に付与するように

ChromeとFirefoxはECH GREASEによって、ECHを使わない接続でも擬似的な encrypted_client_hello 拡張を必ず載せることで、TLSハンドシェイクにECH拡張を常時混在させることで、検閲システムにECH付きなら全部ブロックのような単純な実装をできないようにしています。

https://chromestatus.com/feature/6196703843581952

https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello

ECHの実装

ECHはECHを利用していないリクエストと区別が付かないように以下のようにリクエストを生成します。

  • 既存の公開されるSNI(この記事ではOuter SNIと表現します)にはダミーのドメインを入れる
  • 公開鍵を元に実際に利用するドメインなどの情報を暗号化した上で送信する

なのでダミーのドメインと公開鍵をクライアントは何らかの方法で得る必要があります。そこでDNSのHTTPSレコードが利用されます。以下はtls-ech.devドメインの例です(HTTPSレコードに対応したdigを利用してください)。

$ dig HTTPS tls-ech.dev
(略)

;; ANSWER SECTION:
tls-ech.dev.            60      IN      HTTPS   1 . ech=AEn+DQBFKwAgACABWIHUGj4u+PIggYXcR5JF0gYk3dCRioBW8uJq9H4mKAAIAAEAAQABAANAEnB1YmxpYy50bHMtZWNoLmRldgAA

このbase64エンコードされたデータの中に、主に以下の2つの情報が含まれています。

  • 公開鍵
  • Outer SNIに利用するドメイン名

他にもいくつかの設定が入っていますが、利用者が気にするべきパラメータはこの2つでしょう。

この値を元にクライアントはリクエストを生成します。

CDN側の実装状況

2025年5月時点ではCloudflareが先行して大規模にリリースしています。

https://developers.cloudflare.com/ssl/edge-certificates/ech/

CloudflareではOuter SNIを固定値cloudflare-ech.comに統一しています。cloudflare-ech.comに通信したいユーザーは基本いないはずなので、CloudflareのIPアドレス宛にSNIでcloudflare-ech.comドメインに通信しているようにみえる通信はすべてECHを利用して実際に通信しているドメイン名を秘匿化していると推測することが可能です。このことは検閲に利用される可能性が高いと考えられますし、実際に利用されています。

検閲側の現在の挙動

ロシアはクライアント側のECHが有効かつcloudflare-ech.comがSNIに指定されている通信はECHを利用していると判断してブロックしています。

https://adguard-dns.io/en/blog/encrypted-client-hello-misconceptions-future.html

中国国内ではcloudflare-ech.comはブロックされていないようで、まだECHについては本格的にブロックをしていないようです。しかしこれについても今後の情報を常に追う必要があります。

なおSNI経由での検閲はしており、HTTP/3への対応もされたことが分かっています。

UDPにはRSTパケットの仕様がないので、HTTP/2とHTTP/3で挙動が微妙に違うようですが、現状の中国国内のSNIの検閲はブロッキングしているドメインの通信を行おうとすると、そのIPアドレスへの通信が数分間ブロックされます。数分間とはいえIPアドレス自体がブロックされるということは同じIPアドレスを利用しているサービスが中国国内でブロックされている場合、そのサービスの通信が発生すると中国国内で自分のサービスが影響を受ける可能性があります。

https://upb-syssec.github.io/blog/2025/quic-china/

CDN側で必要な実装

ECHを安定的に提供するためには、まず鍵の自動ローテーション基盤が不可欠です。必要な処理は以下です。

  1. 新しい鍵を全Edgeサーバーにデプロイし、新しい鍵と古い鍵を両方利用できるようにする
  2. DNSのHTTPSレコードを更新する
  3. DNSのTTL+バッファ経過後に古い鍵を全Edgeサーバーから削除する

Cloudflareは数時間ごとに鍵を更新しており、高頻度なローテーションが実際に運用しているとされています。

加えて、検閲リスクへの備えとしてIPプールの分離管理も重要です。ECH通信を行ったIPアドレスがブロックされると、同一IPアドレス上の他ドメインにもブロックが波及する可能性があるため、ECHを許可するトラフィック用と、ECHを無効化しておきたいトラフィック用とでネットワーク帯域を分け、ドメインごとに振り分ける仕組みを整える必要があります。これにより、検閲によるIPブロックが起こっても、影響範囲を特定のサービスや顧客に限定できます。

運用上の課題

高頻度に更新するために、鍵のローテーション時に短時間に全Edgeサーバーに鍵をデプロイできるようにすることと、鍵の配布後に速やかにDNSの設定変更を自動で行う必要があります。鍵の再生成時にECHを利用している全顧客のDNSを変更する必要があるため、ECHを提供するにはCDN事業者側がDNSネームサーバーを直接運用するか、外部DNS事業者との連携強化を行わないと現実的に実装できないはずです。

分散したEdgeサーバーへの鍵デプロイには一定のラグがあり、一部のサーバーにデプロイされない障害が発生すれば接続障害になります。またDNSの更新に失敗したり、TTLを無視するDNSキャッシュの実装があった場合、一部のクライアントが古い鍵を参照し続け、接続障害が発生する可能性もあります。

DNSのTTLについて少し明るい話をすると、ECHを利用する場合は、通信先のドメイン名を秘匿化したいはずです。もしDNSで名前解決を行った後に、そのまま通信を始めてしまうと、どのドメインと通信しているかが分かってしまい、ECHの効果が台無しになります。そのため、ECHを利用する際は、DoHやDoTのようにDNSも暗号化された手段で名前解決を行うことが前提となります。DoHやDoTを利用するということは途中で経由するシステムも少なくなりますし、実装も新しいはずです。以前よりはTTLが守られやすくなるかもしれません。

非中央集権だったインターネットの終焉

もともとインターネットの強みは、分散型で非中央集権的な構造にありました。しかしECHは「木を隠すなら森の中」という発想に基づいた仕組みであり、その”森”とは多くのドメインを抱える大規模サービスのことを指します。結果として、小規模なサービスではなく一部の人気サービスにトラフィックが集中し、インターネットの構造は徐々に中央集権へと傾いていきます。

さらに、HTTP/3の実装や運用には高い技術力とインフラが求められるため、実際に運用できるのは限られた大手企業のみです。こうした背景から、HTTP/3やECHの普及は、インターネットを一部の大企業が支配する構造へと加速度的に近づけていると言えるでしょう。

HTTP/3もECHも、本来は「通信の高速化」や「ユーザーのプライバシー保護」といった善意の目的から生まれた技術です。しかし、それらの技術が結果としてインターネットの中央集権化を促進している現状が、本当に望ましい未来なのかどうかは、これからの歴史が評価していくことになると思います。

最後に

箇条書きで内容をまとめます。

  • ECHはClientHello全体を暗号化し、ドメイン名を秘匿化することで、従来のSNIベースの検閲を回避するための技術です。
  • ブラウザ側ではECH GREASEが常に有効となっており、ECH非対応環境でも見かけ上は常に利用しているように振る舞います。
  • ECHでは公開鍵やOuter SNIをDNSのHTTPSレコード経由で配布しています。
  • ロシアではこの仕組みを検出してブロックしており、中国では現在のところ全面的なブロックは確認されていませんが、SNIベースの検閲は継続中です。
  • 鍵のローテーションやDNSの即時反映など、CDN側には高度な運用体制が求められます。
  • ECHとHTTP/3の普及には高い技術力が必要であり、インターネットの構造は次第に一部の大手CDNや企業に依存する傾向が強まっています。

ECHはユーザーのプライバシーを守るために重要な技術であり、今後のインターネットの基本的なインフラの一部になる可能性を秘めています。しかし、その運用には高い技術力が求められ、検閲や運用上の課題も多く、決して万能な解決策ではありません。

現在進行形で各国の対応やブラウザの実装、CDN側の運用手法などがめまぐるしく変化しており、インターネットの構造そのものに影響を与え始めています。そうした大きな変化の渦中に、私たちは今、立ち会っているのだと思います。

これからのインターネットがどのように変わっていくのか。技術が自由と分散を守る手段として機能し続けるのか。それとも新たな形の集中を生むのか。まだ何も確定していないからこそ、その行く先を見届けていくことが楽しみです。

Discussion