一般面接：TLS Encrypted ClientHelloを安全にデプロイするにはどうすればよいか？

質問と範囲

ある企業がネットワーク仲介者に見える接続先サイト名を削減したいと考えていますが、レガシー端末、TLSインスペクションプロキシ、古い設定の残存を懸念しています。ClientHelloInner、ClientHelloOuter、ECHConfig、DNS公開、sharedまたはsplitトポロジ、鍵ローテーション、ダウングレード耐性を網羅したECHロールアウト、モニタリング、フォールバック計画を設計してください。

RFC 9849はECHをサーバーの公開鍵でClientHelloを暗号化するものとして定義し、RFC 9848はSVCBおよびHTTPSレコードを介した設定公開を定義しています。ECHは選択されたハンドシェイクメタデータを保護します。IPアドレス、トラフィックパターン、あるいはエンドポイント自体を隠すものではありません。

面接官がテストしていること

公開用のouterエンベロープ、実際のinnerハンドシェイク、そしてそれを誰が復号して転送するかの説明。
ECHConfigソース、設定識別子、鍵ローテーション、DNSキャッシュの一貫性の説明。
明示的な信頼境界と証明書境界を伴うsharedモードとsplitモードの比較。
ECHがあらゆるトラフィックを匿名化するという誤った主張を避け、IP、DNS、トラフィック分析、エンドポイントについて議論すること。
レガシー端末、ミドルボックス、インスペクション、retry_configs、安全でないダウングレード経路の処理。
受理率、再試行、ハンドシェイクエラー、ポリシーヒットのメトリクスを用いたロールアウトの検証。

最初に明確にすべき質問

目的は一般の観測者からSNIを隠すことですか、それともエンタープライズのインスペクション、地域ポリシー、コンプライアンス上の保持要件を満たすことも含みますか？
クライアントのDNSリゾルバーとブラウザポリシーは誰が管理していますか？レガシー端末、モバイルネットワーク、企業プロキシの割合はどの程度ですか？
1つのサービスがTLSを終端しますか、それともエッジプロバイダーが復号してバックエンドに転送しますか？
許容されるDNS TTLと鍵の重複期間はどれくらいですか？また、インシデント発生時にECHを一時的に無効化できますか？
どのメトリクスで実際のドメインやユーザーIDを除外する必要があり、ログはどれくらいの期間保持されますか？

30秒の回答

まず脅威モデルを定義します。ECHはClientHello内の実際のサイト名を隠しますが、IPアドレスやトラフィックパターンは隠しません。サーバーはECHConfigを公開し、クライアントは暗号化されたinnerと公開用のouterを構築し、エッジが復号してinnerをバックエンドに渡します。カナリアリリースを実施し、受理率、再試行、ハンドシェイクエラーを測定し、重複期間を設けて鍵をローテーションします。レガシー端末は通常のTLSを使用できますが、ECHの失敗によって実際のSNIが無防備に露出してはなりません。企業ポリシーは、テスト済みの安全なフォールバックを備えた制御されたDNSまたは明示的なプロキシ境界へと移行すべきです。

ステップバイステップの詳細解説

1. 保護境界を定義する

ECHにより、観測者は実際のSNIではなく公開名またはエッジサービスを見ることになります。IPアドレス、タイミング、パケットサイズ、DNSが暗号化されていない場合のDNSクエリ、エンドポイントの証明書ポリシーからは依然として情報が漏洩する可能性があります。目標は接続の匿名化ではなく、ハンドシェイクメタデータの削減であると定義します。

2. innerとouterのフローを説明する

クライアントはECHConfigから鍵とパラメータを選択し、実際のClientHelloをClientHelloInnerに入れ、ClientHelloOuter拡張を含むencrypted_client_helloを構築します。outerには公開名が使用されます。エッジはそれを認証・復号し、innerをバックエンドに渡します。攻撃者がouterのフィールドを変更できないよう、サーバーはouterの関連データを認証します。

text

DNS HTTPS/SVCB -> ECHConfig(public name, key, config_id)
client -> encrypt(ClientHelloInner) -> ClientHelloOuter
edge -> decrypt and validate -> backend handles ClientHelloInner

3. sharedまたはsplitトポロジを選択する

sharedモードでは、1つのサービスがクライアントと対峙し、バックエンドのTLSを終端します。splitモードでは、エッジがECHを復号し、独立したバックエンドにinnerを転送します。splitモードにはエッジ・バックエンド間の明示的な信頼関係、証明書、接続保護、障害責任の所在が必要です。エッジは無条件に安全な平文観測者であるわけではありません。

4. 設定の公開と鍵のローテーション

制御されたTTLでHTTPS/SVCBレコードにECHConfigを公開し、ローテーション中は新旧両方の設定を提供します。各設定には公開鍵、バージョン、識別子が含まれます。DNSキャッシュ、設定の選択、復号失敗を監視します。古い秘密鍵は、キャッシュ、接続、再試行の各ウィンドウが経過した後にのみ破棄します。

5. 障害とレガシー端末の処理

ECH非対応のクライアントは通常のTLSを使用できます。ECH対応クライアントはretry_configsを受信した後に設定を更新できます。アクティブな攻撃者がSNIの漏洩を誘発する可能性があるため、RFC 9849はECH拒否後にクライアントが単に暗号化されていない実際のClientHelloを送信することを禁止しています。サーバーは、考えられるすべてのエンドポイントに公開名で有効な証明書をプロビジョニングする必要があります。

6. ミドルボックスと企業ポリシーの処理

ECHを理解しないTLS終端プロキシは公開outer名を使用して接続する可能性があるため、SNIベースのインスペクションが一致しなくなる場合があります。ポリシーを制御されたDNSリゾルバー、明示的なプロキシ、または管理されたブラウザ境界に移行し、ポリシーをバージョン管理します。DNSの変更が無害であると決めつけず、DNSSEC、地域ネットワーク、緊急無効化のリハーサルを行います。

7. カナリアリリースと観測

まず1つのサイト、地域、および制御されたクライアントコホートで有効化します。ECH受理率、ech_required、再試行率、TLS失敗、DNSキャッシュヒット、エンドツーエンドのレイテンシを比較します。実際のinner SNIをデフォルトで記録することなく、設定識別子、エッジロケーション、エラークラスをログに記録します。ハンドシェイク、ポリシー適用、互換性に後退が見られた場合は、グローバルにダウングレードするのではなく、サイトまたはクライアント単位で限定的に無効化します。

質の高い模範解答

ECHをIPやトラフィックパターンの匿名化ではなく、SNIプライバシーの強化として位置付けます。DNSがECHConfigを公開した後、クライアントは実際のClientHelloInnerを暗号化し、公開名を含むClientHelloOuterを送信します。エッジはそれを検証・復号し、明確に文書化されたsharedまたはsplit信頼モデルに基づいてinnerをTLSバックエンドに渡します。

まずはカナリアリリースを行い、重複する設定とTTLウィンドウを用いて鍵をローテーションし、設定の選択、受理率、retry_configs、ech_required、ハンドシェイクエラー、レイテンシを監視します。レガシー端末は通常のTLSを使用できますが、ECH対応クライアントは意図的に引き起こされた失敗の後に実際のSNIを露出させてはなりません。SNIに依存するエンタープライズ制御はDNSまたは明示的なプロキシに移行します。ログには秘匿化された識別子とエラークラスのみを保持し、ロールバックとDNSSECのシナリオをリハーサルしておきます。

よくある間違い

ECHがIPやすべてのトラフィック特徴を隠すと主張する → 脅威モデルが過大評価されています → 選択されたClientHelloメタデータを保護することを明記してください。
DNSキャッシュとローテーションの設計なしに鍵を公開する → クライアントが古い設定を保持し続けます → TTL、重複期間、破棄条件を定義してください。
ECHの失敗後に実際のSNIを平文で送信する → アクティブな攻撃者が情報漏洩を誘発する可能性があります → 拒否、再試行、安全な終了ルールに従ってください。
エッジの復号を信頼不要な平文処理として扱う → splitモードの境界が欠落しています → エッジ、バックエンド、証明書、リンク保護の責任を明確にしてください。
成功したハンドシェイクのみを測定する → レガシーおよびエンタープライズの後退が見落とされます → クライアント、ネットワーク、地域、エラークラスごとにセグメント化してください。

フォローアップの質問と回答

ECHはDNSの漏洩を防ぎますか？

いいえ。ECHConfigは通常HTTPS/SVCBレコードを介して取得されるため、暗号化されていないDNS経路ではクエリが公開される可能性があります。ECH、暗号化DNS、証明書、ネットワークポリシーは個別に評価してください。

splitモードでエッジは何を見ることができますか？

エッジはECHを復号してinnerを転送する必要があるため、ハンドシェイク処理に必要な情報は見えます。アプリケーションの可視性は、後続のTLSがどこで終端するかによって異なります。最小限の信頼、リンク保護、ログの境界を文書化してください。

失敗後に通常のClientHelloで再試行しないのはなぜですか？

アクティブな攻撃者がECHの失敗を引き起こし、実際のSNIの漏洩を誘発する可能性があるためです。安全な実装では、クライアントのフォールバックルール内でretry_configs、公開名認証、または接続終了を使用します。

ECH鍵はどのようにローテーションしますか？

DNS TTL、接続寿命、再試行ウィンドウの間、古い設定を保持しながら新しい設定を公開します。設定識別子ごとにヒットと復号失敗を監視し、重複期間が経過した後に古い秘密鍵を破棄します。

企業がSNIを検査する必要がある場合はどうしますか？

ポリシーと法的境界を明確にし、制御されたDNSリゾルバー、明示的なプロキシ、またはエンドポイント管理ポリシーを選択的に使用します。DNSの書き換えにDNSSEC、互換性、可用性のコストが伴わないと想定してはなりません。

TLSの成功率は横ばいなのに受理率が低下しています。何を調査しますか？

DNSリゾルバー、クライアントバージョン、エッジロケーション、設定識別子を比較します。HTTPSレコードのキャッシュ、鍵バージョン、公開名証明書、retry_configsを確認し、設定の移行とハンドシェイク障害を区別します。