概要
- RFC 9849は TLS の ClientHello メッセージ暗号化方式を定義
- Encrypted Client Hello (ECH) 拡張でクライアント情報の秘匿性向上
- SNIやALPNなど 機密情報の漏洩を防止
- Shared Mode と Split Mode の2つの運用形態に対応
- HPKE を用いた公開鍵暗号と詳細な構成仕様を記述
TLS Encrypted Client Hello（ECH）概要
- TLS 1.3 ではハンドシェイクの大部分が暗号化されるが、 ClientHelloのSNI （Server Name Indication）など一部は平文で送信され、プライバシーリスクが残存
- 本RFCで定義される Encrypted Client Hello (ECH) は、 ClientHello全体をサーバ公開鍵で暗号化 する新しいTLS拡張方式
- ECHにより、 SNIやALPNリスト などの機密情報がネットワーク経路上で秘匿される
- ECHは TLS 1.3、 DTLS 1.3 およびそれ以降のバージョンでサポート
- IETF による標準化、広範なレビューと合意を経て策定
ECHの運用モード
- Shared Mode
- サービスプロバイダが全てのドメインのオリジンサーバとして機能
- TLS接続の終端もサービスプロバイダが担当
- Split Mode
- サービスプロバイダはプライベートドメインのオリジンサーバではない
- DNSレコードはサービスプロバイダを指し、TLS接続はプロバイダ経由でオリジンサーバに中継
- サービスプロバイダはハンドシェイクの平文部分以外の通信内容にアクセス不可
- client-facing server （クライアント向けサーバ）と backend server （バックエンドサーバ）という役割分担
- Shared Modeでは同一、Split Modeでは物理的に分離
ECHの動作概要
- サーバは ECH構成情報 （公開鍵とメタデータ）を公開
- DNS経由やプリセットなど複数の配布方法に対応
- クライアントは ClientHelloInner （機密情報入り）と ClientHelloOuter （外部公開用）を生成
- ClientHelloOuterに encrypted_client_hello拡張 を付与し、ClientHelloInnerを暗号化して格納
- サーバは受信時に
- ECH非対応または復号失敗時はClientHelloOuterでハンドシェイク継続（ECH拒否）
- 復号成功時はClientHelloInnerをbackend serverに転送しハンドシェイク（ECH受理）
- クライアントはサーバ応答から ECHが受理されたか判定 し、失敗時は再試行可能
ECHのセキュリティ・プライバシー目標
- 同一匿名性セット 内のサーバへの接続が識別不能となることが主目的
- 既存TLS 1.3のセキュリティ特性を損なわない設計
- DNSやIPアドレスなど他経路からの情報漏洩は、 DNS over HTTPS や DNS over TLS/QUIC 等の併用で補完
ECH構成仕様
- Hybrid Public Key Encryption (HPKE) を用いた公開鍵暗号方式を採用
- ECH構成（ECHConfig）は以下の要素で構成
- version ：ECHバージョン識別子
- length ：構成データ長
- contents ：ECHConfigContents構造体
- ECHConfigContentsの主なフィールド
- key_config ：HPKE公開鍵や暗号スイート情報
- maximum_name_length ：バックエンドサーバ名の最大長（パディング計算用）
- public_name ：client-facing serverのDNS名
- extensions ：拡張情報リスト
- HpkeKeyConfig の主なフィールド
- config_id ：1バイトの構成識別子（クライアントが暗号化時に利用）
- kem_id ：HPKE KEM識別子
- public_key ：HPKE公開鍵
- cipher_suites ：KDF/AEADの組み合わせリスト
- サーバは複数のECHConfigを 優先順でリスト化 して配布し、クライアントは対応可能なものを選択
ECHの導入・運用上の注意点
- ECHの導入により利用者のプライバシーが大きく向上
- ただし、 DNSやIPアドレスでの情報漏洩対策 も併用が望ましい
- サーバのTLS構成や挙動が一致していることが匿名性セットの成立条件
- 実装の詳細や運用上の注意点はRFC本文および関連RFC（RFC9460, RFC9848等）を参照
（必要に応じて、次のセクションや詳細仕様、実装ガイドラインなどを新たなタイトルで展開できます）