SNI はなぜ見えていたのか ― TLS Encrypted ClientHello(ECH)と HTTPS の最後の平文

HTTPS は、ブラウザとサーバーの間の通信を TLS で暗号化します。TLS 1.3 では、サーバー証明書を含むハンドシェイクの多くも暗号化されるようになりました。しかし、接続の最初に送る ClientHello は、相手のサーバーと暗号鍵を合意する前に必要なメッセージです。その中に、接続したいホスト名を示す server_name 拡張、つまり SNI が含まれていました。

ClientHello
  supported_versions: TLS 1.3
  server_name: private.example.com   # 従来はここが平文
  alpn: h2, http/1.1
  key_share: x25519...

SNI は、1つのIPアドレスで複数のHTTPSサイトを運用するために重要です。サーバーは SNI を見て、どの証明書を出すべきか、どの仮想ホストへルーティングすべきかを判断できます。つまり、SNI はプライバシー上は弱点ですが、Webホスティングの実務上は必要な情報でした。

TLS 1.3 は TLS 1.2 以前に比べて、ハンドシェイクの秘匿性を大きく改善しました。特に、サーバー証明書が平文で流れなくなった点は大きな変化です。証明書にはドメイン名が含まれるため、TLS 1.2 では証明書を見るだけでも接続先を推測できました。

しかし、TLS 1.3 でも最初の ClientHello は暗号化前に送る必要があります。そこで SNI や ALPN など、接続先や利用プロトコルを推測できる情報が残りました。RFC 9849 は、平文SNIを「TLS 1.3で残った最も感度の高い情報」の一つとして位置づけ、ECHでこの問題に対処します。

ECH の中心は、ClientHello を二重構造にする発想です。クライアントは、本当に接続したい名前や機密性の高い拡張を入れた ClientHelloInner を作り、それをサーバー側の公開鍵で暗号化します。そして、外から見えてもよい値を入れた ClientHelloOuter に、暗号化した Inner を載せて送ります。

ClientHelloOuter
  server_name: public.example.com
  encrypted_client_hello: Enc(ClientHelloInner)

ClientHelloInner
  server_name: private.example.com
  alpn: h2
  key_share: ...

観測者から見ると、接続先は公開名 public.example.com に見えます。一方、ECHを復号できるクライアント向けサーバーは、暗号化された ClientHelloInner を取り出し、実際のバックエンドや証明書処理へ進めます。ここで重要なのは、ECHが「SNIだけを暗号化する」のではなく、ClientHelloの機密部分をまとめて隠す設計になっていることです。

ECH の前身には ESNI(Encrypted SNI) がありました。名前の通り、ESNI は SNI だけを暗号化する方向で始まりました。しかし、実際の ClientHello には SNI 以外にも接続先や利用アプリケーションを推測できる情報があります。ALPN、PSK、拡張の組み合わせ、拡張の順序などが、観測者にヒントを与える可能性があります。

そのため、SNIだけを特別扱いで暗号化しても不十分です。RFC 9849 の ECH は、ClientHelloInner 全体を暗号化し、外側には匿名集合の中で揃えやすい情報を置く構造に変わりました。名称も ESNI から ECH へ変わったのは、保護対象が「server_name だけ」ではなくなったことを反映しています。

これは、プライバシー機能としてかなり大事な設計変更です。隠したい値を1個だけ暗号化しても、周辺のメタデータから同じことが推測できるなら意味が薄い。ECHはその反省を取り込んでいます。

クライアントが ClientHelloInner を暗号化するには、サーバー側の公開鍵や対応方式を事前に知る必要があります。この設定情報が ECHConfig です。RFC 9849 は ECHConfig の構造を定義し、DNSでの配布方法は RFC 9848 が扱います。

現代のDNSには、HTTPSレコードやSVCBレコードという、サービス接続に必要な追加情報を渡す仕組みがあります。ECHでは、クライアントが名前解決の段階でHTTPS/SVCBレコードを取得し、その中の ech パラメータから ECHConfigList を得る流れが基本になります。

DNS HTTPS/SVCB record
  svc priority / target name
  alpn=h2,h3
  ech=base64(ECHConfigList)

ここで注意したいのは、DNSが平文のままだと名前解決の段階で接続先が見えることです。ECHはTLSのClientHelloを守る仕組みであり、DNS問い合わせそのものを暗号化するわけではありません。そのため、DoH(DNS over HTTPS)、DoT(DNS over TLS)、DoQ(DNS over QUIC)などの暗号化DNSと組み合わせて初めて、観測点を大きく減らせます。

RFC 9849 は、ECH の代表的な配置として Shared Mode と Split Mode を説明しています。Shared Mode は、クライアントから見えるサーバーと実際のTLS終端が同じ場所にある構成です。CDNやリバースプロキシが複数のドメインをまとめて終端する場合は、このイメージに近くなります。

Split Mode は、クライアント向けサーバーとバックエンドサーバーが分かれている構成です。クライアント向けサーバーが ECH を受け取り、暗号化された ClientHelloInner をバックエンド側へ渡すことで、公開名と実際のサービス名を分離できます。

どちらのモードでも大事なのは、匿名集合です。ECHは「インターネット上で何にも接続していないように見せる」技術ではありません。外からは、同じクライアント向けサーバーやCDNに収容された複数のサービスのどれかに接続しているように見える、という性質を目指します。

ECH は強力ですが、万能の匿名化技術ではありません。何を隠せて、何を隠せないかを分けて考える必要があります。

たとえば、専用IPに1つのサイトしか載っていない場合、SNIを隠してもIPアドレスから接続先を推測できます。一方、大きなCDNや共有ホスティングのように、同じIPや同じクライアント向けサーバーに多くのドメインが集まる環境では、ECHの効果が出やすくなります。

ECH は、失敗したら静かに平文SNIへ戻ればよい、という設計ではありません。RFC 9849 では、サーバーがECHを復号できない場合や設定が古い場合、クライアントはECHの受理・拒否を判定し、必要に応じて新しい設定で再試行します。ECHが拒否された接続は、そのままアプリケーションデータに使うものではない、という考え方です。

これはダウングレード攻撃への対策として重要です。もし攻撃者がECHをわざと失敗させ、ブラウザがそのまま平文SNIで接続し直すなら、ECHの保護は簡単に剥がされてしまいます。実装は、ECHを試した事実、サーバーからの応答、設定の更新を慎重に扱う必要があります。

同時に、互換性も課題になります。古いミドルボックス、企業ネットワークの監視装置、古いTLS終端、DNSのHTTPS/SVCB対応など、ECHはTLSだけでなく周辺の配信基盤にも影響します。

一般的なWebアプリ開発者が、ECHを自前で実装する場面はほとんどありません。多くの場合、ブラウザ、OS、CDN、DNS事業者、TLSライブラリ、リバースプロキシの対応に乗ることになります。ただし、仕組みを理解しておくと、セキュリティ説明やネットワーク設計で判断を間違えにくくなります。

• CDNやDNSプロバイダーが HTTPS/SVCB レコードとECHをどう扱うか確認する
• DoH/DoT/DoQなしではDNS問い合わせが観測されることを説明できるようにする
• 専用IPか共有CDNかで、ECHの匿名集合の大きさが変わることを理解する
• 企業ネットワークや監査環境では、ECHが可視化運用と衝突する可能性を把握する
• 「HTTPSならドメイン名も完全に見えない」と単純化して説明しない

また、ECHはポスト量子暗号とは別のテーマです。どちらもTLSの将来に関わりますが、ECHは接続先メタデータの秘匿、ML-KEMなどのポスト量子暗号は将来の計算能力に対する鍵交換・署名の耐性が主題です。

HTTPSは最初から完璧だったわけではありません。HTTP本文が暗号化され、TLS 1.3で証明書を含むハンドシェイクの多くが暗号化され、それでも残ったSNIという大きな平文に対して、ECHが標準化されました。

ECHは、ClientHelloInner を暗号化し、外側の ClientHelloOuter には公開名や互換性のための情報を置くことで、本当の接続先ドメインを観測者から見えにくくします。DNSのHTTPS/SVCBレコード、ECHConfig、DoH/DoT/DoQ、CDNの匿名集合が組み合わさって、はじめて効果が大きくなります。

一方で、IPアドレス、通信量、タイミング、平文DNS問い合わせまではECH単体では隠せません。だからこそ、ECHは「匿名化の魔法」ではなく、HTTPSのメタデータ漏れを一段減らす標準技術として理解するのが正確です。