プロンプトと適用範囲
TLS 1.3はハンドシェイク内容の大部分を暗号化しますが、従来のClientHelloはSNIを露出させ、オブザーバーがターゲットサービスを推測することを可能にしてしまいます。ECHのプロトコル上の役割、鍵設定の配信、障害時の動作を説明し、SNIの隠蔽とすべてのトラフィック特性の隠蔽との違いを明確にしてください。
これは、ネットワーキング、セキュリティ、プラットフォーム、および一般的なプロトコル関連の職種に適しています。その核となるスキルはTLSハンドシェイクとプライバシーの境界であるため、generalに属します。
面接官が見ているポイント
第1に、outerとinnerのClientHelloを理解しているか？ClientHelloOuterは互換性のための形状を提供し、実際のターゲットはサーバーの設定済み公開鍵で暗号化されたClientHelloInnerに配置されます。
第2に、設定の配信を説明できるか？ECHConfigには公開鍵とアルゴリズムのメタデータが含まれています。DNS SVCB/HTTPSレコードを介して発見できますが、信頼性と鮮度（freshness）が依然として重要です。
第3に、ECHがエンドツーエンドの匿名性ではないことを理解しているか？DNS、IP、タイミング、証明書、およびECHを使用しないパスからは、依然として情報が漏洩する可能性があります。
第4に、障害時のフォールバックを説明できるか？ECHが利用できない場合、クライアントは再試行するか、通常のClientHelloを送信することがあります。ポリシーにおいて、失敗したプライバシー試行を成功とみなしてはなりません。
第5に、検証を設計できるか？HTTPSの成功のみをチェックするのではなく、ハンドシェイク拡張、エッジのメトリクス、設定のヒット率、およびフォールバック率を検査します。
最初に明確にすべき質問
- クライアント、エッジプロキシ、およびTLSライブラリはRFC 9849をサポートしているか？
- ECHConfigはどのように配信され、DNSSECや暗号化DNSはどのように処理されるか？
- そのサービスには共有フロントエンドと複数のバックエンド名が存在するか？
- プレーンテキストSNIへのフォールバックは許可されているか、それともプライバシーの失敗はハードフェイル（hard failure）とする必要があるか？
- 保護対象はドメイン、テナント名、それともより広範なトラフィックメタデータか？
- テレメトリは内部名をログに記録せずにECHの成功を記録できるか？
30秒の回答フレームワーク
「ECHは実際のターゲットをClientHelloInnerに配置し、ECHConfigで公開された公開鍵を使用してHPKEで暗号化します。ClientHelloOuterはハンドシェイクの互換性を維持します。ECHConfigはDNS SVCB/HTTPS経由で配信でき、信頼性と鮮度のチェックが行われます。障害発生時、ポリシーに基づいてフォールバックまたはハードフェイルが選択されますが、TLSの成功はプライバシーの成功を意味するわけではありません。検証では、DNS、IP、トラフィックパターンが依然として可視であることを認識しつつ、ハンドシェイク拡張、エッジメトリクス、設定ヒット、およびフォールバック率を組み合わせます。」
ステップバイステップの回答
ステップ 1: 2つのClientHelloメッセージを分離する
クライアントは、隠蔽したい実際のSNIと拡張機能を含むClientHelloInnerを構築し、次に互換性メッセージとしてClientHelloOuterを作成します。サーバーまたはエッジはECHConfigの鍵を使用して内部メッセージを復号します。復号できない場合は、プロトコルに従って障害を処理します。
ステップ 2: HPKEと設定を理解する
ECHConfigには、バージョン、公開鍵、暗号スイート、およびサーバーメタデータが含まれます。クライアントはHPKEを使用してClientHelloInnerを保護し、サーバーは一致する秘密鍵を保持します。ローテーションには、有効期限のオーバーラップ、キャッシュ制御、および失効が必要です。鍵をクライアントにハードコードしてはなりません。
config = fetch_ech_config()
inner = build_client_hello(real_sni, extensions)
outer = build_outer_hello(public_name, ech_extension)
encrypted_inner = hpke_seal(config.public_key, inner)
send(outer, encrypted_inner)ステップ 3: DNS配信と信頼性を検討する
ECHConfigはSVCB/HTTPSレコードを介して発見できます。鮮度、キャッシュ、および改ざんのリスクを評価します。暗号化DNSはパスの一部のみを保護しますが、DNSSECとアプリケーションポリシーが信頼性を決定します。無効または期限切れの設定がある場合は更新します。
ステップ 4: 障害とフォールバックを定義する
復号の失敗、期限切れの設定、GREASE、または拡張機能の非互換性により、再試行または通常のハンドシェイクがトリガーされる場合があります。どのドメインでフォールバックを許可し、どのプライバシー要件でハードフェイルが必要かを決定し、その理由を記録します。フォールバックはECHの成功ではありません。
ステップ 5: 残存する露出を特定する
ECHはClientHello内のターゲット名を隠蔽しますが、DNSクエリ、宛先IP、タイミング、パケットサイズ、証明書、およびアプリケーションの動作によって、依然としてトラフィック分析が可能です。目標は匿名性ではなく、特定のハンドシェイクメタデータの露出を減らすことであると述べてください。
ステップ 6: デプロイと鍵ローテーションを計画する
最小権限と監査証跡を適用してエッジ秘密鍵をデプロイし、新旧の設定をオーバーラップさせて公開します。マルチリージョンキャッシュには、一貫したバージョン管理と無効化が必要です。鍵が侵害された場合は、古い設定を失効させ、TTLを短縮し、フォールバック率を監視します。
ステップ 7: エンドツーエンドの受け入れ基準を構築する
ECHあり/なしのクライアント、複数のDNSパス、および複数のエッジノードでテストします。拡張機能のネゴシエーション、設定バージョン、復号失敗、フォールバック率、ハンドシェイクラテンシ、および接続エラーを記録します。パケット検証において、機密性の高い内部名をログに記録してはなりません。
模範解答
「ECHはTLSハンドシェイク拡張機能であり、アプリケーション層のトンネルではありません。クライアントは実際のSNIをClientHelloInnerに配置し、ECHConfigの公開鍵を使用してHPKEで暗号化し、互換性のあるClientHelloOuterを送信します。ECHConfigはSVCB/HTTPSを介して発見できるため、デプロイではDNSの信頼性、キャッシュ、およびローテーションに対処する必要があります。
私なら障害ポリシーを明示的に定義します。プライバシーに敏感なエンドポイントはハードフェイルさせ、互換性エンドポイントでは通常のフォールバックを観測可能にします。テレメトリは、内部名をログに記録することなく、ネゴシエーション、設定ヒット、復号失敗、フォールバック、およびハンドシェイクラテンシを網羅します。DNS、IP、証明書、およびトラフィックパターンについては、別途プライバシー分析が必要です。受け入れ検証は、クライアント、DNSパス、および鍵ローテーションに及びます。」
よくある間違い
- ECHがすべてのトラフィックを隠すと主張する → DNS、IP、タイミングは依然として可視 → 限定されたプライバシー目標を述べる。
- ECHConfigの鍵をハードコードする → ローテーションと失効が困難になる → 更新可能な設定を使用する。
- HTTPSの成功のみをチェックする → 通常のフォールバックがECHとしてカウントされる → 拡張機能とフォールバック理由を記録する。
- DNSの改ざんや古いキャッシュを無視する → クライアントが不正な設定を使用する → 信頼性、TTL、および更新を評価する。
- 外側のSNIを実際のターゲットとして扱う → 互換性名が誤解される → パブリック名と内部SNIを分離する。
- オーバーラップなしで鍵をローテーションする → マルチリージョンのクライアントで断続的な障害が発生する → オーバーラップと無効化の計画を使用する。
- 内部名をログに記録する → テレメトリによってプライバシーが再漏洩する → ハッシュ、バージョン、および状態のみをログに記録する。
- 非対応クライアントを無視する → 実ユーザーが接続できなくなる → 明示的なフォールバックまたはハードフェイルのルールを維持する。
フォローアップの質問
フォローアップ 1: ECHとDoH/DoTはどのように関連していますか？
ECHはTLS ClientHelloを保護し、DoH/DoTはDNSトランスポートを保護します。これらは異なる段階に対処するものであり、組み合わせることができますが、どちらか一方が他方を置き換えるものではありません。
フォローアップ 2: なぜClientHelloOuterが必要なのですか？
ECHを理解しないミドルボックスでもハンドシェイクを処理できるように互換性の形状を提供する一方で、実際のターゲットは暗号化された内部メッセージ内に留められます。
フォローアップ 3: ECHは障害時に常にフォールバックする必要がありますか？
いいえ。ポリシーはプライバシーと可用性の要件によって異なります。プライバシーに敏感なエンドポイントはハードフェイルする可能性があり、互換性エンドポイントはフォールバックする可能性がありますが、それを観測可能かつカウント可能にする必要があります。
フォローアップ 4: ミドルボックスがECHを壊していないことをどのように検証しますか？
クライアント、エッジ、およびサーバーでネゴシエーションを個別に記録し、プロキシパス全体で成功、フォールバック、およびハンドシェイクエラーを比較します。
フォローアップ 5: 鍵が侵害された後はどうなりますか？
古いECHConfigを失効または公開停止し、キャッシュTTLを短縮し、新しい鍵をデプロイして、復号失敗とフォールバックを監視します。過去に露出したClientHelloを遡及的にプライベートにすることはできません。
フォローアップ 6: ECHは証明書内のドメイン名を隠蔽しますか？
主にハンドシェイク内のターゲット名を隠蔽します。証明書、DNS、IP、およびアプリケーション情報は依然としてドメインを関連付ける可能性があるため、完全なドメイン隠蔽を保証することはできません。