言語: English | 日本語

はじめに — セキュリティの可視性が直面する危機

正常なパターンを表示し、脅威が見当たらないため、完全に機能しているように見えるレーダー画面を想像してください。安心しているその間にも、気付かないうちに、高度な航空機がまったく検知されずに空域へ侵入しています。レーダーは稼働し、画面も表示されていますが、迫る本当の危険はまったく見えていません。暗号化技術がかつてない速さで進化する今、ネットワークセキュリティの担当者が直面しているのは、まさにこのような状況です。ファイアウォールもセキュリティシステムも動作し続けていますが、脅威がネットワーク内を自由に移動する一方で、重要な可視性が、気付かないうちに失われつつあります。

以下の数値は、元の 2025 年 12 月の記事で報告された推定値です。出典によって母集団が異なり、今回の更新では再測定していません。

インターネットトラフィックの 90% 超が暗号化されており、現在、そのほぼ半分が QUIC を使用して従来の TCP 検査を回避しています。
HTTP/3 の普及が加速しています。HTTP/3 は、QUIC の暗号化された UDP トランスポート上でのみ動作します。
HTTP/2、HTTP/3、QUIC 上の暗号化 DNS により、クライアントは企業の DNS 制御を完全に回避できます。
ブラウザの 59% が Encrypted Client Hello（ECH）に対応しており、宛先情報を隠すことで、TLS/QUIC ハンドシェイクで最後まで平文で見えていた情報も見えなくなります。
ブラウザの 57% がすでに耐量子計算機暗号を使用しており、量子コンピュータによる将来の攻撃に備えています。

QUIC、HTTP/3、Encrypted Client Hello、耐量子計算機暗号という技術が組み合わさることで、ネットワークによる保護に大きく依存した従来のセキュリティアプローチの能力を大幅に低下させる、暗号化プロトコルスタックが生まれています。

可視性がなければ、セキュリティは成り立ちません。新たな暗号化スタックによって状況が見えなくなりつつあるにもかかわらず、監視機器はすべて正常であるかのように表示し続けています。

❗️
セキュリティアプライアンスは稼働し、ポリシーも維持されています。しかし、セキュリティ上の判断を支える可視性は失われつつあります。

こうした課題の中でも、Encrypted Client Hello は、現在のセキュリティ環境においてネットワークの可視性に対する最も大きな脅威かもしれません。ECH とは何か、なぜ重要なのか、組織はどのように備えられるのかを詳しく見ていきます。

SNI が非常に重要な理由

ECH を理解する前に、何が影響を受けるのかを振り返ります。TLS プロトコルは、Client Hello と呼ばれるハンドシェイクメッセージから始まります。このメッセージは、従来、平文で送信されていました。そのため、Server Name Indication（SNI）などのメタデータが公開され、通信経路上の中間装置は、その情報を観測し、セキュリティやコンプライアンスのためのポリシー判断など、さまざまな目的で利用できます。平文の SNI によって接続先ドメインが分かるため、ファイアウォールは、その他の送信データが暗号化されたままでもセキュリティ機能を実行できます。SNI 拡張は、TCP の 3 ウェイハンドシェイクの直後、TLS ネゴシエーション中に平文で送信されるため、通信経路上のどのデバイスからも容易に観測できます。

SNI は容易に偽装でき、まったく送信しないこともできるため、設計上、それ自体を信頼できるものではありません。そのため、ネットワークセキュリティデバイスは SNI をそのまま信頼することはありません。まず最初の手掛かりとして利用し、その後、追加の確認によって情報を検証します。たとえば、Server Identity Probe を使用して、SNI とサーバ証明書を比較します。SNI がセキュリティ上有用なのは、この検証プロセスがあるためです。SNI は絶対的に正しい情報源ではなく、より詳細な検査と検証の出発点です。

現在のネットワークセキュリティ基盤は、SNI 拡張に大きく依存しています。SNI は、これまで「次世代」ファイアウォールと呼ばれてきた製品のセキュリティ判断の多くを支えています。

URL カテゴリおよびレピュテーションによるフィルタリング — 悪意のあるサイトや不適切なサイトをブロックします。
アプリケーション識別 — ファイアウォールを通過させるアプリケーションを把握します。
Security Intelligence URL — Talos が把握した既知の悪意のあるドメインをブロックします。
TLS Server Identity Probe — SNI の偽装を防ぎ、復号の精度を高めます。
TLS/QUIC の選択的な復号 — 詳細な検査が必要な接続を判断します。
高度な検査機能 — IPS、マルウェア保護、脅威インテリジェンスを提供します。

❗️
SNI が見えなければ、上記の重要なセキュリティ機能は大きく損なわれるか、まったく機能しなくなります。 その結果、セキュリティデバイスは稼働していても、本来の宛先が隠されるため、詳細な検査の対象とならないトラフィックの割合が増加します。適切な理解と準備がなければ、ネットワーク管理者はこの事実にすら気付かず、セキュリティポリシー違反や侵害の兆候を見逃す可能性があります。

Encrypted Client Hello（ECH）の影響

Encrypted Client Hello は、プライバシー保護の支持者が「SNI のセキュリティギャップ」と考える問題を解消するための、最後の要素です。ECH は、Server Name Indication と、その他の機密性の高いハンドシェイクパラメータを暗号化します。このメタデータを隠すことで、ユーザのプライバシー保護、特定の Web サイトを狙ったブロックの防止、インターネット全体のセキュリティ向上に役立ちます。ECH は正当なプライバシー強化を目的として設計されましたが、ネットワークデバイスによるトラフィックのフィルタリングに基づく、組織の現在のセキュリティ戦略に大きな課題をもたらします。ECH により、ネットワークベースのセキュリティアプライアンスは、ユーザがアクセスしている具体的な Web サイトを確認できなくなります。単一のコンテンツ配信ネットワーク（CDN）プロバイダーの SNI の背後に、数万もの Web アプリケーションが隠れる、1 対多の関係が生じます。

ECH で保護されたトラフィックを扱う場合、ファイアウォールは次のことができなくなります。

通信の実際の宛先を識別する。
SNI の申告内容をサーバ証明書と照合して検証する。
どのトラフィックを検査する必要があるかを、十分な情報に基づいて判断する。
宛先のコンテキストに基づいてセキュリティポリシーを適用する。
詳細な検査のために TLS および QUIC を選択的に復号する。

以下の例では、ECH に対応するブラウザと CDN の基盤を示します。対応状況は、クライアントのバージョンやサービスの設定によって異なります。元の記事ではドラフト 25 を説明していました。その後、ECH は RFC 9849 として標準化されています。

本記事の例では、ECH 対応 CDN として Cloudflare を使用しています。元の 2025 年 12 月の記事では、ECH 対応率として、上位 10K の Web サイトの 4.2%[1]、上位 1M の Web サイトの 9.2%[2]、ブラウザの 59%[3] が報告されていました。これらは元の記事の数値と母集団の表記を再掲したものです。参照先のデータセットは異なるため、比較や再利用を行う前に、母集団と測定日を確認してください。サービスプランでの提供状況や制御方法は、プロバイダーの最新ドキュメントで確認してください。

プライバシーが攻撃に利用されるとき — 実際の ECH 悪用事例

ECH によって生じる可視性の欠落は、組織のセキュリティ制御を回避しようとする攻撃者に、絶好の機会を与えます。過去の他のプロトコルと同様に、気付かれずに通信する機会は、防御の回避を狙う攻撃者にすぐに取り入れられます。こうした手法を利用することで、攻撃者は、より少ない労力で、検知される可能性を下げながら目的を達成できます。

2024 年初頭、NTT Security Holdings の研究者が、日本の組織を狙った標的型攻撃の分析中に、実際のマルウェアの脅威を検出しました[4]。研究者は、コマンド & コントロール（C2）通信に ECH を利用する高度なマルウェアを特定しました。

「注目すべきマルウェアを特定しました。[...] C&C 通信に Encrypted Client Hello（ECH）を利用する点が特徴的で、[...] 従来のセキュリティ製品では検出とブロックが大幅に難しくなります。」
— Yuta Sawabe & Rintaro Koike、NTT Security Holdings

ECHidna は ECH を利用し、従来のセキュリティ基盤からネットワークアクティビティを隠します。C2 トラフィックは、CDN 基盤への正当な接続に見えますが、実際の悪意のあるホストは ECH によって隠されたままです。Encrypted Client Hello を使用すると、通常ならマルウェアの活動を検出してブロックできる制御、すなわちドメインのブロックリスト、URL フィルタリング、選択的に復号する不審なトラフィックの識別などを回避できます。

これは実際の事例の 1 つにすぎません。しかし、これまでの経緯から、気付かれずに通信する手法は、攻撃者の間で非常に速く広まることが分かっています。近いうちに、次のような動きが予想されます。

C2 通信に ECH を組み込む新たなマルウェアファミリー。
データの持ち出しを隠すために ECH を使用するランサムウェアグループ。
長期にわたる潜伏に ECH を利用する APT キャンペーン。
標準的な回避手法として ECH を採用する汎用マルウェア。

❗️
ECHidna の発見は、ECH の脅威が理論上のものではないことを示しています。 脅威はすでに存在しています。ECH による可視性の欠落への対処を始めていない組織では、悪意のあるトラフィックがすでに検出されずに流れている可能性があります。

Encrypted Client Hello の動作の流れ

ECH がもたらす脅威と、その防御方法を十分に理解するには、実際の動作の仕組みを知る必要があります。その処理は驚くほど洗練されており、まさにそれが危険性につながっています。

📘
技術的な流れを見る前に、ECH がどれほど容易に利用できるようになったかを理解しておくと役立ちます。ECH 対応サービスの構築は、インターネット上に Web サーバを設置し、ECH をデフォルトで有効にする CDN プロバイダーの無料プランに登録するだけで済みます。無料プランでは、ECH を無効にできない場合もあります。つまり、数千もの Web サイトが、追加の費用や専門知識なしに CDN の ECH 基盤の背後へ隠れることができます。導入の障壁は事実上なくなっており、ECH が急速に普及している理由になっています。

次の図は、対応 Web ブラウザを使用するクライアントと、無料プランで ECH 基盤を標準提供する CDN の背後にホストされたテスト Web サーバ「pig-in-the-middle.pl」との間で行われる、Encrypted Client Hello の一連の流れを示しています。

DNS 設定の公開 — Web サーバのフロントエンドに ECH 対応 CDN を配置し、そのドメインを CDN に委任すると、CDN の基盤に名前解決される一連の DNS レコードが自動的に公開されます。
HTTPS レコードによる ECH 設定の提供 — 通常の A レコードと AAAA レコードに加えて、CDN は、次の ECH 設定を含む HTTPS レコードを公開します。
- ECH のクライアント向けサーバの公開名（例：cdn-ech.example.com）。
- Hybrid Public Key Encryption（HPKE）用の公開鍵。
  この ECH 設定は、実際の接続先を中間のセキュリティデバイスに明かすことなく、ECH フロントエンドを経由してサーバに到達する方法をクライアントに伝えます。
クライアントによる ECH 設定の取得 — ユーザが pig-in-the-middle.pl にアクセスしようとすると、ブラウザは次の処理を行います。
• パブリックリゾルバに、暗号化 DNS クエリ（DNS over HTTPS または DNS over HTTP/3 を使用）を送信します。
• IP アドレスと ECH 設定の両方を受信します。
• 実際の宛先を暗号化するために必要な公開鍵を取得します。

❗️
企業のセキュリティ制御で、この暗号化 DNS クエリを確認またはブロックできなければ、防御の最初の層はすでに突破されています。クライアントは、気付かれずに接続するために必要な情報をすべて取得した状態です。

‼️
高度な攻撃者は、ECH 設定をマルウェアのバイナリにハードコーディングしたり、一見無害な公開サービス（ブログ記事、YouTube の説明、GitHub リポジトリなど）から取得したりすることで、DNS 監視を完全に回避する場合があります。このため、DNS 制御は、一般的なブラウザトラフィックや高度でない脅威に対して不可欠かつ有効ですが、強い意図を持った攻撃者に対する唯一の防御策にはできません。

2 つの Client Hello を使ったクライアントから CDN への接続 — 前のステップで ECH 設定を取得したクライアントブラウザは、CDN のクライアント向けサーバに接続する準備が整います。ここに ECH の特に巧妙な仕組みがあります。クライアントは、別々の Client Hello メッセージを 2 つ作成します。
- Inner Client Hello（暗号化） — セキュリティデバイスが検査したい実際の接続情報が含まれます。実際の SNI である pig-in-the-middle.pl もその 1 つです。この内側のメッセージは、DNS から取得した公開鍵で暗号化され、HPKE（Hybrid Public Key Encryption）で保護されたペイロードになります。
- Outer Client Hello（観測可能） — ファイアウォールを含むネットワーク上の観測者が実際に確認し、セキュリティポリシーの評価に利用できるメッセージです。クライアントは、CDN プロバイダーの ECH エンドポイントへ接続し、一般的な TLS パラメータだけを公開して、実際の宛先は明かしません。技術的には、このペイロードの SNI は、ECH のクライアント向けサーバの公開名（cdn-ech.example.com）です。このサーバでは、数千もの異なる Web サイトがホストされている可能性があります。Outer Client Hello は、暗号化された Inner Client Hello を TLS 拡張として格納し、中間装置はその内容を確認できません。
エッジサーバによる Inner Client Hello 拡張の復号 — この TLS Client Hello が CDN のエッジ（クライアント向けサーバ）に到達すると、次の処理が行われます。
- サーバは、DNS 経由で配布した公開鍵に対応する秘密鍵を使って Inner Client Hello を復号し、実際の宛先が pig-in-the-middle.pl であることを把握します。
- サーバは、復号した Inner Client Hello をバックエンドサーバへ転送します。

📘
ここで示す分離モードの構成では、クライアント向けサーバが Inner Client Hello を復号し、接続をバックエンドサーバへ中継します。TLS はバックエンドサーバとクライアントの間で終端されます。クライアント向けサーバは転送経路上に残りますが、アプリケーショントラフィックは復号しません。

TLS ハンドシェイクの完了 — バックエンドサーバは、実際の SNI（pig-in-the-middle.pl）を含む平文の Inner Client Hello を使用して TLS ハンドシェイクを完了します。
安全で、接続先を隠した接続の確立 — クライアントブラウザは、セキュリティ基盤を含むインターネット上の観測者に実際の宛先を明かすことなく、対象サーバへ安全に接続します。

Encrypted Client Hello の検出が難しい理由

ECH の検出における重要な課題は、拡張の存在だけでは、本物の ECH と GREASE のカバートラフィックを確実に区別できないことです。ECH 利用の有無による識別・選別を防ぐこの設計により、ECH の使用だけに基づく選択的なブロックが難しくなります。RFC 9849 のセクション 6.2.1 では、接続先サーバの ECH 設定を持たないクライアントに対し、最初の Client Hello で GREASE ECH 拡張を送信することを推奨（SHOULD）しています。これは条件付きの推奨であり、すべてのブラウザのすべての接続に対する必須要件ではありません。このため、クライアントは、次の場合でもダミー拡張を送信することがあります。

対象サーバが ECH に対応していない場合。
TLS 接続が実際には ECH を使用していない場合。
クライアントが対象サーバの ECH 設定を持っていない場合。

❗️
ECH 拡張を含む接続をすべてブロックすると、実際には ECH をネゴシエートしていない GREASE の HTTPS 通信にも支障が生じる可能性があります。このため、拡張の存在だけを根拠に、本物の ECH 接続だけを確実にブロックすることはできません。

次に、Wireshark でキャプチャした 2 つの TLS Client Hello パケットを示します。一方には、暗号化された宛先情報を持つ本物の ECH 拡張が含まれています。もう一方には、プレースホルダにすぎないダミーの「GREASE」ECH 拡張が含まれています。ファイアウォールからは、両者は同じように見え、実用的な方法で区別することはできません。ダミー拡張の構造は、ダミーの Cipher Suite、Config ID、ランダム化された疑似暗号化ペイロードを使用して、ECH ペイロードを忠実に再現しています。

🧑‍🔬
理論上は、インターネット上のすべての DNS HTTPS レコードを検索し、特定の接続と一致する ECH 設定が含まれるかどうかを確認できます。しかし、DNS データの規模と動的な性質を考えると、この方法をリアルタイムに実装することは極めて困難です。

プロトコル仕様では、サーバの応答から Encrypted Client Hello のネゴシエーションが成功したかどうかを判断できないようにしています。次に、前述の Client Hello パケットに対する 2 つの Server Hello 応答を示します。一方では ECH が受け入れられ、もう一方では受け入れられていません。ファイアウォールやその他のネットワーク中間装置からは、両者はまったく同じように見えます。これらのメッセージには、この段階でサーバが提供する標準の TLS 拡張が含まれていますが、ECH が受け入れられたことを直接示す情報はありません。

クライアントは、Server Hello の random 値の最後の 8 バイトを、Inner Client Hello の random 値と内側のハンドシェイクのトランスクリプトから計算した確認値と比較し、ECH が受け入れられたかどうかを判断します。内側のハンドシェイク情報を持たない中間装置は、この確認値を検証できません。これは確認値の照合であり、HPKE の鍵でこの 8 バイトを復号する処理ではありません。詳細は RFC 9849 のセクション 7.2 を参照してください。

上記のデコード済みキャプチャでは、確認値から ECH が受け入れられたことを確認できます。検証には、対応する内側のハンドシェイク情報が必要です。その情報を持たない通常の経路上の観測者は、同じ照合を行えません。

📘
上記の Wireshark キャプチャで ECH が受け入れられたことを確認できるのは、接続を開始したエンドポイントをデバッグモードにし、TLS 鍵ログファイルを収集したためです。通常、この情報は暗号学的に保護されており、取得できません。

ECH は、セキュリティの観点からは扱いにくいプロトコルですが、その設計は美しく、洗練された暗号技術、ECH 利用の有無による識別・選別を防ぐ、考え抜かれた仕組み、円滑なフォールバック動作を備えています。現実的な防御戦略を構築するには、動作の理解が不可欠です。

ECH 拡張の存在だけでは、本物の ECH と GREASE のカバートラフィックを確実に区別できません。
サーバの応答も判断材料にはなりません。ECH が受け入れられたかどうかは、暗号学的に中間装置から隠されています。
ECH 拡張を一律にブロックすると、実際の ECH をネゴシエートせずに GREASE を使用する HTTPS 接続にも支障が生じる可能性があります。
この設計は意図的なものです。ECH 利用の有無による識別・選別を防ぐことは、プロトコルの中心的な目標です。

ECH 利用の有無による識別・選別を防ぐ設計と検出上の課題は、これから説明する実践的な防御戦略を理解するうえで不可欠な背景です。単純に ECH をブロックすることはできませんが、Cisco Secure Firewall は、こうした制約がある中でも、連携して可視性とセキュリティを維持するための複数の機能を提供します。

Cisco Secure Firewall での Encrypted Client Hello への対処

ファイアウォールで ECH 接続を認識する方法

ECH がセキュリティログにどのように現れるかを理解することが、課題に対処する第一歩です。Cisco Secure Firewall で ECH 接続がどのように表示されるか、セキュリティチームがどのようなパターンに注意すべきかを確認します。

📘
次の例では、実際の宛先である「pig-in-the-middle.pl」サーバへの接続がファイアウォールポリシーで明示的に拒否されています。それにもかかわらず、ECH によって接続が成功し、セキュリティルールを回避しています。

ユーザが ECH で保護された Web サイトに接続すると、通常、Unified Events Viewer には、次の特徴的な 2 段階のパターンが表示されます。

暗号化 DNS 接続：
- ブラウザが暗号化 DNS リゾルバ（例：mozilla.cloudflare-dns.com）にクエリを送信し、クライアント向けサーバの公開鍵を含む ECH 設定を取得します。
- ファイアウォールは、パブリックリゾルバに向かう暗号化 DNS トラフィックを認識しますが、問い合わせたドメイン（pig-in-the-middle.pl）や、返された ECH パラメータは確認できません。
ECH 接続：
- ブラウザは CDN のクライアント向けサーバ（例：cloudflare-ech.com）に接続し、TLS 接続を確立した後、バックエンドサーバ（pig-in-the-middle.pl）とアプリケーショントラフィックを交換します。
- ファイアウォールには Outer Client Hello の SNI = cloudflare-ech.com が見えますが、実際の宛先（pig-in-the-middle.pl）は分かりません。

⚠️
禁止された宛先への接続がブロックされない
上記のログからは、CDN の背後にある実際の Web サイトを確認できません。隠された接続先ドメインを条件とするルールは、外側の SNI だけではそのドメインに一致させられません。一方、以下の「ECH Servers」AppID の例のように、可視の CDN プロバイダーに一致するルールは適用できます。

Cisco は VDB 416（2025 年 10 月リリース）[6] から、「ECH Servers」アプリケーションディテクタを導入しました。これにより、ファイアウォールは既知の ECH 対応 CDN プロバイダーへの接続を識別でき、どのトラフィックが ECH による隠蔽を使用している可能性が高いかを把握できます。この検出器は、ECH サービスを提供する大手 CDN プロバイダーに関連するトラフィックパターンに一致し、次のことを可能にします。

環境内で、既知のプロバイダーを識別する AppID に一致するトラフィックを監視する。
ECH 対応の宛先を対象とするポリシーを作成する。
ECH 対応の接続先へのトラフィックのベースラインを確立する。ただし、ECH のネゴシエーション成功数を検証した値ではありません。

❗️
ファイアウォールルールで ECH トラフィックをブロックしないでください
ECH 対応の CDN エンドポイントをブロックすると、接続障害や長いタイムアウトが発生し、ブラウザごとに予測できない動作になります。

一部のブラウザは、接続エラーを表示して平文 SNI へのフォールバックを拒否し、そのサイトへのアクセスがまったくできなくなる場合があります。

他のブラウザは、長いタイムアウト（1 回あたり 15 秒超）を伴う再試行を複数回行い、フォールバックまでに最大 2 分の遅延が生じる場合があります。

このため、組織全体でユーザ体験にばらつきが生じ、利便性が低下します。ECH 接続をブロックする代わりに、以下で説明する選択的な復号によるダウングレードを検討してください。この方法では、ユーザへの影響を大幅に抑えながら、平文 SNI へフォールバックさせることができます。

ECH 設定の初期取得の防止

ECH に対する最も効果的な防御は、クライアントが ECH 設定を最初に取得できないようにすることです。クライアントが ECH の公開鍵とパラメータを受信しなければ、ECH を使用できず、平文 SNI へ円滑にフォールバックします。ECH は、初期設定の配布を DNS に依存しています。具体的には、クライアントは次の情報を取得します。

ECH 公開鍵（Inner Client Hello の暗号化用）と HPKE 暗号化パラメータ。
クライアント向けサーバの公開名。

この情報がなければ、ブラウザやアプリケーションは ECH で保護された接続を構築できません。そのため、DNS の可視性と制御は極めて重要です。

Cisco Secure Firewall には、暗号化 DNS トラフィックを識別してブロックするために特別に設計されたアプリケーションディテクタが含まれています。

アプリケーションディテクタを使用して、次の暗号化 DNS プロトコルを照合できます。

DNS over HTTPS（DoH）
DNS over TLS（DoT）
DNS over HTTP/3（DoH3）
DNS over QUIC（DoQ）

📘
重要な例外
Cisco Umbrella を使用している場合は、「DNS Crypt」アプリケーションをブロックしないでください。このアプリケーションは Umbrella のセキュア DNS サービスに一致するため、ブロックすると、自社のセキュリティ基盤に支障をきたします。

❗️
高度な攻撃者は、ECH 設定をハードコーディングしたり、別の経路（ブログ記事、YouTube 動画の説明、PasteBin.com など）から取得したりすることで、DNS 監視を回避できます。
それによって DNS 制御が無意味になるわけではありません。DNS 制御は、次のような対象に対して引き続き高い効果を発揮します。

一般的なブラウザによる ECH の使用（トラフィックの大部分）。

高度でないマルウェアや脅威。

ブラウザのデフォルト動作に依存する、機会を狙った攻撃者。

DNS 制御は、大部分の ECH 接続を止め、高度な攻撃者に必要なコストと労力を増やす、境界のフェンスのようなものと考えてください。厳格な DNS 制御で ECH の量を最小限に減らすことにより、残った ECH 接続を集中的に監視でき、不自然な動作を通じて悪意のあるアクティビティを検出する可能性が高まります。

TLS/QUIC の復号と ECH 拡張の除去による ECH 接続のインターセプト

DNS 制御が回避された場合や、高度な脅威に対応する場合など、ECH 接続がファイアウォールまで到達したときには、Cisco Secure Firewall の機能を使用して、ECH 仕様の「secure disable（安全な無効化）」の仕組みを動作させることができます。

図示した TCP/443 の例では、ファイアウォールが TLS をインターセプトし、「encrypted_client_hello」拡張を除去します。クライアントは外側のハンドシェイクを続行します。ECH が安全に無効化されたと判断するには、そのハンドシェイクを正常に完了し、証明書が ECHConfig.contents.public_name に対して有効であることを検証する必要があります。置換 CA を信頼しているだけでは不十分です。認証済みのサーバから、クライアントが対応するバージョンの再試行設定が提供されなかった場合、クライアントは ECH が安全に無効化されたと判断でき、ECH を無効にして新しいトランスポート接続で再試行することが推奨（SHOULD）されます。アプリケーションデータを送信する前に、最初の接続を「ech_required」で中止します。この例は QUIC の動作を検証したものではありません。詳細は RFC 9849 のセクション 6.1.6–6.1.7 を参照してください。

最初の接続は暗号化 DNS で、クライアントは「pig-in-the-middle.pl」サーバの ECH 設定を取得します。
次のエントリには、「cloudflare-ech.com」への ECH 接続が記録されています。ファイアウォールはこの接続をインターセプトし、復号を試みます。内部では、次の処理が行われます。
- クライアントが、実際の対象サーバの識別情報を保護する、暗号化された ECH 拡張を含む TLS Client Hello を送信します。
- ファイアウォールの復号設定は、「ECH Servers」AppID を使用して、既知の ECH プロバイダーへの接続をインターセプトして復号するように構成されています。
- ファイアウォールは、クライアントが信頼する InternalCA を使用し、再署名（key-resign）方式でこの接続を復号します。これは重要なステップです。ECH が「安全に無効化された」と判断するためには、クライアントが、検査対象のハンドシェイクでファイアウォールにより再署名された証明書を信頼している必要があります。
- ファイアウォールは、クライアント側とサーバ側の TLS 接続を別々に終端する中間装置として動作し、TLS Client Hello を「cloudflare-ech.com」サーバへ転送する際に、ECH 拡張を除去します。
- ハンドシェイク要求に ECH 拡張が含まれていないため、ECH フロントエンドサーバは、自身が実際の接続先であり、クライアントから ECH がまったく提案されていなかったかのように、TLS ハンドシェイクを進めます。
- TLS ハンドシェイクが正常に完了すると、クライアントは ECH 仕様に従って、サーバにより ECH が「安全に無効化された」と判断します。これは、サーバが ECH ネゴシエーションの成功を示さず、フォールバック用の「ech configuration」も提供しなかったためです。
- TLS 接続では対象サーバに到達できなかったため、クライアントはアプリケーションデータを送信せず、「ech_required」アラートでこの接続を中止します。
ECH が安全に無効化された状態で、次の処理が行われます。
- クライアントは、ECH を使用せず、平文 SNI を含む新たな TLS 接続で再試行します。これにより、実際の宛先が明らかになります。
- この接続はファイアウォールによって正しく識別され、意図どおりポリシーでブロックされます。

次の図は、既知の ECH プロバイダーへの接続に一致し、復号する復号ポリシーのルールの設定例です。このルールは「Decrypt - Resign」アクションを使用し、「ECH Servers」AppID に一致するように設定されていることに注意してください。ファイアウォールが対象サーバの証明書を模倣するために使用する InternalCA オブジェクト「TLS_Decrypt_SubCA」は、ECH 接続を試みるエンドポイントから信頼されている必要があります。

Cisco Secure Firewall の復号ルールでは、「ECH Servers」AppID を使用して、既知の ECH 対応 CDN プロバイダーへのトラフィックを選択できます。このプロバイダーへの一致は、一致したすべての接続で実際の ECH がネゴシエートされたことを証明するものではありません。図示したダウングレードの流れでは、後続の接続で平文 SNI が公開され、アクセスコントロールと検査に利用できます。この方法により、次のことが可能になります。

ペイロード全体を検査するオーバーヘッドをかけずに可視性を回復する。
明らかになった宛先に対して、URL フィルタリングとレピュテーションチェックを適用する。
実際の宛先について、十分な情報に基づいて選択的な復号を判断する。
セキュリティ効果を最大化しながら、パフォーマンスへの影響を最適化する。

👍
この方法は、ECH のダウングレードによって可視性を回復し、宛先が明らかになった後で、リスクの高い宛先だけを検査する柔軟性を提供します。

❗️
この手法が機能するのは、クライアントがファイアウォールの代替証明書を信頼している場合だけです。内部 CA を信頼されたルート証明書リポジトリにインストールできないゲストデバイスには適用できません。

Encrypted Visibility Engine による ECH 接続内の不審なアクティビティの検出

ECH によって宛先が隠され、復号が導入されていない場合でも、Encrypted Visibility Engine（EVE）は TLS および QUIC のハンドシェイクフィンガープリントから、クライアントプロセスに関するコンテキストを追加できます。推定されたプロセス名と信頼度スコアは調査に役立ちますが、それだけでエンドポイント上の実行や悪意の有無が確定するわけではありません。EVE は、隠された接続先を明らかにするものではありません。詳細は EVE コンフィギュレーションガイドを参照してください。

次の例では、SNI が「cloudflare-ech.com」の ECH 接続が確立され、EVE フィンガープリントには「chromium browser」と表示されています。Encrypted Visibility Engine は、この接続の実際の宛先を特定しないことに注意してください。実際のサーバ「pig-in-the-middle.pl」は隠されたままです。

EVE による送信元プロセスのフィンガープリントがもたらす価値を、もう少し詳しく見ていきます。セキュリティの観点から見ると、ユーザのブラウザから発生する ECH 接続は、主に可視性の問題です。宛先が隠されていると、管理者はコンテンツフィルタリングポリシーを適用できず、Encrypted Visibility Engine もこの問題を解決するものではありません。

ECH によって接続先が隠されている場合、EVE のプロセスフィンガープリントは調査のコンテキストを提供します。ECH 対応 CDN へのトラフィックで非ブラウザのフィンガープリントが検出された場合、追加分析の対象となり得ますが、それだけでマルウェアと確定するわけではありません。次の図には、Firefox、Chrome、「generic dmz process」、「rancher desktop」という 4 つの接続ラベルが表示されています。

この例では、外側の SNI だけを見ると、各接続の接続先は「cloudflare-ech.com」と表示されます。EVE は、ブラウザおよび非ブラウザのプロセスフィンガープリントを追加し、調査の優先順位付けに役立ちます。不明なプロセスのラベルは、他の証拠と照合する必要があります。

調査候補の接続を確認するには、Firewall Management Center の Unified Events で「ECH Servers」AppID に一致するように絞り込み、「!firefox browser」や「!chromium browser」のように、一般的なブラウザの EVE Process Name を除外します。次のスクリーンショットでは、「docker」および「gnu wget」とラベル付けされた 4 つの接続が表示されています。悪意のある接続と判断する前に、信頼度スコアと他の証拠を確認してください。

接続ログを手動で確認する代わりに、Cisco Secure Firewall の相関ポリシーを使用して、不審な ECH 使用の検出を自動化できます。次に示す相関ルールの例では、一般的な Chrome または Firefox ブラウザ以外の EVE フィンガープリントを持つ、「ECH Servers」AppID に該当する既知の ECH サーバ宛ての接続がファイアウォールに記録されると、直ちにルールがトリガーされます。ルールに一致したときに、電子メールまたは Syslog アラートを送信したり、自動修復アクションを実行したりするように、Management Center を設定できます。ほぼリアルタイムのアラート機能により、ログを手動確認する負担を軽減します。

EVE は、接続先が隠されている場合でも、フィンガープリントに基づくクライアントプロセスのコンテキストを暗号化接続に追加します。プロセスおよび脅威の信頼度スコアを他の証拠と組み合わせ、マルウェアの C2 チャネルの可能性を含め、通常と異なる非ブラウザのトラフィックを調査してください。

👍
EVE は、アプリケーションのペイロードを復号せずに、フィンガープリントに基づく可視性を提供します。追加調査が必要かどうかを判断する際には、接続のコンテキストとともに、プロセスおよび脅威の信頼度スコアを確認してください。

📘
Cisco Secure Firewall では、Encrypted Visibility Engine、「ECH Servers」AppID、相関ポリシーを使用することで、ECH による隠蔽の下で本来ならまったく見えない脅威を検出し、その対応を自動化できます。

3 層の保護アプローチ

ECH は、隠された接続先に依存する従来のセキュリティ制御で利用できる情報を減らします。一律のブロックは、本物の ECH と GREASE の両方のトラフィックに影響する可能性があります。可視性とセキュリティを維持するには、導入環境の機能に応じて、DNS、エンドポイント、接続検査の各層の制御を組み合わせます。

第 1 層：DNS 制御 — クライアントによる ECH 設定の取得を防ぎます。
第 2 層：エンドポイント管理 — 送信元で ECH と暗号化 DNS を無効にします。
第 3 層：選択的な復号と振る舞い検知 — 残った ECH 接続をダウングレードし、異常を検出します。

各層は、設定の取得前、エンドポイントレベル、接続確立時という異なる段階で ECH に対処します。この方法では段階的な防御を行うことで、セキュリティ態勢に対する ECH の影響を大幅に軽減します。

第 1 層 — DNS 制御

ECH に対する最も効果的な防御は、クライアントが ECH 設定を最初に取得できないようにすることです。DNS は、初期取得用の ECH 設定を配布する主な手段です。設定が提供されなければ、クライアントは自然に平文 SNI へフォールバックします。

承認済みの企業 DNS を使用している場合でも、ECH 設定の初期取得を防ぐように DNS フィルタリングを設定します。DNS 基盤が対応している場合は、DNS リゾルバで次の処理を行うように設定します。
- HTTPS レコードから ECH パラメータを完全に除去する。
- 既知の ECH 対応ドメインの HTTPS レコードをブロックする。
  ❗️
  ECH 設定は平文 DNS でも配布できます。このため、HTTPS レコードから ECH 設定を除去することは、暗号化 DNS に対する制御を補完します。暗号化 DNS は、初期ルックアップのプライバシー保護にも役立ちます。詳細は RFC 9849 のセクション 10.2 を参照してください。
Firefox でデフォルト有効の DoH を対象とする場合に、カナリアドメインを使用します — Mozilla のカナリアドメインの説明に従い、企業の DNS リゾルバが「use-application-dns.net」に対して否定応答を返すように設定します。これは Firefox に、デフォルトで有効になった DoH を無効にするよう通知する仕組みです。ユーザが手動で有効にした DoH には適用されず、他のブラウザや DoT、DoQ を一律に制御するものでもありません。
ファイアウォールで、Cisco Secure Firewall のアプリケーションディテクタを使用して、暗号化 DNS プロトコルを識別してブロックします。
- DNS over HTTPS（DoH）
- DNS over TLS（DoT）
- DNS over HTTP/3（DoH3）
- DNS over QUIC（DoQ）
承認済み DNS リゾルバだけを許可するファイアウォールルールを作成します — すべての DNS クエリが、管理・フィルタリングされた自社の基盤を通過するようにします。
- 企業の DNS サーバに対する、DNS の UDP/TCP ポート 53 を許可する。
- それ以外の DNS トラフィックは、宛先を問わずすべてブロックする。
- クライアントがパブリックリゾルバ（例：1.1.1.1、8.8.8.8 など）に到達できないようにする。

❗️
DNS 制御は境界のフェンスと考え、より強い意図を持った攻撃者であれば、ECH 設定をマルウェアにハードコーディングする可能性があると想定してください。また、ECH のリカバリ（retry_configs による再試行）メカニズムを使用して、サーバから最新の ECH 設定を直接取得したり、別の経路（ブログ記事、ソーシャルメディア、GitHub リポジトリなど）から取得したりする可能性もあります。

第 2 層 — エンドポイント管理

エンドポイントを管理できる場合は、ブラウザの設定で ECH と暗号化 DNS を直接無効にできます。これは、クライアントレベルで機能する第 2 の防御層です。

ブラウザのポリシーテンプレートを展開します — 構成管理ツールを使用し、暗号化 DNS プロトコルとハンドシェイクでの実際の ECH の使用を無効にして、OS の DNS 設定に従うブラウザポリシーを展開します。
設定をロックします — ユーザがブラウザ設定から暗号化 DNS や ECH を再度有効にできないようにします。これにより、ユーザが回避を試みた場合でも、ポリシーを適用し続けられます。
可能なすべての場所で上記のルールを展開します — 管理対象デバイス、BYOD デバイス、契約業者のデバイスすべてに展開します。

この方法では、管理対象エンドポイントからネットワークに発生する ECH をさらに減らせますが、ゲストデバイス、管理対象外の IoT、ブラウザポリシーを無視する高度なマルウェアには機能しません。

第 3 層 — 選択的な復号と振る舞い検知

DNS 制御とエンドポイントポリシーにより、管理対象環境での ECH の使用を減らせます。残った接続については、クライアントがファイアウォールの置換 CA を信頼し、対応が確認されてテスト済みの組み合わせに限って、TLS/QUIC の選択的な復号を評価してください。前述のダウングレード例で示したのは TCP/443 の動作です。残ったトラフィックの異常な振る舞いの調査には、Encrypted Visibility Engine を使用します。

既知の ECH プロバイダーに対して選択的な復号を設定します — 「ECH Servers」AppID に一致する「Decrypt - Resign」復号ルールを適用し、平文 SNI への円滑なダウングレードを促します。接続の復号時に、ファイアウォールは最初の要求から ECH 拡張を除去し、クライアントが ECH を「安全に無効化」するように仕向けます。

🚧
ECH 拡張を除去するために TLS ハンドシェイクへ介在すると、クライアントとサーバの間でアプリケーションデータを交換しなくても、ファイアウォール全体の復号負荷が増加します。中間者として機能するには、ファイアウォールが復号する他の接続と同様に、2 つの TLS 接続を別々に確立し、鍵ペアをリアルタイムに生成する必要があります。
この手法を「ECH Servers」に選択的に適用する際は、ファイアウォールの負荷を監視し、前述の DNS フィルタリングとエンドポイント管理によって、ECH トラフィック量がすでに削減されていることを確認してください。

📘
この手法は、ユーザのマシンが、ファイアウォールによって模倣された証明書を信頼する場合にだけ適用できる、ECH の弱点を利用します。ゲストネットワークや、クライアントがファイアウォールを信頼していない場合には機能しません。

Encrypted Visibility Engine を有効にして、通常とは異なる ECH 接続を検出します — エンドポイントの非ブラウザプログラムから既知の CDN への不審な接続を調査します。不明なバイナリが生成する ECH 接続に注目してください。

👍
EVE は、クライアントプロセスのフィンガープリントと信頼度スコアを、暗号化トラフィックの調査に提供します。不審な動きを評価する際は、他のネットワークやエンドポイントの証拠と組み合わせてください。

選択的な復号は、証明書を信頼している管理対象デバイスで ECH をダウングレードします。一方、EVE による監視は、平文 SNI への切り替えを促せなかった残りの接続について、異常な ECH 使用の検出を可能にします。

防御戦略のまとめ

3 層のアプローチは ECH 自体をなくすものではありませんが、対処不能に見える問題を、管理できる問題に変えます。ECH を完全に止めることはできません。しかし、その設定配布を制御し、可能な場所では無効化し、必要に応じてダウングレードし、悪用を検出できます。この 3 層を組み合わせることで、現在だけでなく、今後 ECH の普及が加速する中でも、ECH を利用した脅威に対する包括的な防御を提供します。

免責事項

元の記事の著者は、2025 年 12 月にテストおよび検証を行ったと報告しています。図示したダウングレード例では TCP/443 を使用しています。この例は、QUIC を独立に検証した結果でも、すべての FTD/FMC リリース、モデル、ブラウザのビルド、CDN の組み合わせでの動作を示すものでもありません。導入前に、リリース固有の対応状況を確認し、自社環境で動作をテストしてください。実装には、次の制限もあります。

元の 2025 年 12 月の記事では、ECH ドラフト 25 について説明していました。その後、ECH は RFC 9849 として標準化されています。 各手法は、自社環境に導入しているプロトコルと実装に対して検証してください。
本記事で説明した手法が、あらゆる場合に機能するとは限りません。ブラウザ、ブラウザのバージョン、CDN プロバイダー、基盤コンポーネントの組み合わせによっては、期待どおりに動作しない場合があります。組織には、本番環境のセキュリティ制御として依存する前に、自社の環境でこれらの手法を十分にテストすることを推奨します。

これらの例は、元の著者の管理された環境に基づきます。適用可能性は、導入したソフトウェア、クライアントの動作、証明書の信頼関係によって異なります。Cisco は、各手法が今後も無期限に有効であり続けることや、あらゆる導入シナリオで機能することを保証しません。