2026年3月、RFC 9849: TLS Encrypted Client Hello というインターネット標準のプロトコル仕様が発行されました。(正確には “Proposed Standard” ではありますが、標準と呼んで差し支えないでしょう。)
この Encrypted Client Hello (以降 ECH と表記します) は、プライバシー保護という観点では望ましい技術ですが、Cato クラウドのようにセキュリティ機能を提供するサービスとは相性が悪い面があります。具体的には、ECH によって Cato が通信先のドメイン名を正しく認識できなくなり、セキュリティポリシーが適切に機能しなくなる可能性があります。
本記事では、ECH が Cato クラウドの動作にどのような影響を与えるのか、そしてどう対応すべきなのかを解説します。
TLS Encrypted Client Hello とは
ECH については2年前のブログでも少し触れていましたが、その当時の懸念は少々杞憂でした。
ECH とは何かざっくりと言いますと、TLS 通信においてクライアントが接続するサーバのドメイン名を保護するプロトコルです。ドメイン名そのものを機密にするものではなく、クライアントがどのドメイン名と通信するかを機密にするものです。
これまで、通信先のドメイン名を保護する技術として DNS 通信を暗号化する技術 (DNS over TLS / HTTPS / QUIC) や DNS の QNAME minimisation がありました。
それらによって名前解決の段階では通信先のドメイン名を保護できるものの、その後の TLS 通信を開始する際にクライアントが最初に送信する Client Hello メッセージにはサーバのドメイン名が暗号化されずに格納されています。そのため、通信経路上の監視者はクライアントの通信先のドメイン名を覗き見ることができてしまいます。
この課題を解決するために、通信先のドメイン名を暗号化して Client Hello に格納できるようにする標準技術として ECH が生まれました。
ECH の通信の流れ
基本的な通信の流れ
ECH の基本的な通信の流れは次のようになります。
まず、クライアントは DNS の HTTPS レコードの名前解決を行い、ECH を作成するための暗号鍵とダミーのドメイン名を取得します。HTTPS レコードというものに馴染みのない方も居るかもしれませんが、2023年11月に標準化された DNS の新しいレコードタイプです。
次に、クライアントは TLS 接続を開始する際、本物のドメイン名を暗号化して Client Hello メッセージに埋め込み、外から見えるドメイン名の部分にはダミーのドメイン名を格納して送信します。これにより、本物のドメイン名を保護しつつ、通信経路上の監視者にはダミーのドメイン名と通信しているように見せることができます。
その後、サーバは Client Hello メッセージ内の暗号化されたデータを復号し、本物のドメイン名を取り出して適切に処理することで、最終的に TLS 接続が確立します。
TLS Inspection が有効な場合の通信の流れ
Cato のように経路上で TLS Inspection を行う場合、通信の流れが少し変わってきます。
Cato が TLS Inspection を行う場合、Cato はサーバに成り代わって Client Hello メッセージを処理します。その際、Cato はメッセージ内の暗号化されたデータを復号できないため、本物のドメイン名を取り出すことができず、ECH にも対応していない Server Hello メッセージをクライアントに返すことになります。
クライアントは返ってきた Server Hello メッセージを見て、ECH が機能しないことを検知し、その TLS 接続をエラー終了させます。その後、ECH を使わない通常の TLS 接続にフォールバックし、本物のドメイン名を暗号化せずに Client Hello メッセージに格納して送信します。
それを受信した Cato は TLS を適切に処理できますので、クライアントと Cato との間で TLS 接続が正常に確立します。
ECH が Cato の通信に与える影響
ECH による TLS 接続が確立した場合、Cato はダミーのドメイン名しか認識できないため、本物のドメイン名に基づくセキュリティポリシーを適用できないことになります。さらに、本物のドメイン名を正しく認識できないことから、ドメイン名をもとに Cato が分類しているアプリケーションカテゴリやリスクスコアなどによる制御も適切に機能しなくなります。
そのため、Cato の基本的なセキュリティ機能である Internet Firewall や IPS に影響があり、本来ブロックすべき通信が通過してしまうという問題を引き起こします。
なお、ECH による TLS 接続が確立するということは TLS Inspection が有効ではない状態でもありますので、TLS Inspection が有効であることを前提としたセキュリティ機能 (IPSの一部、Anti-Malware、CASB、DLP など) には影響がありません。また、ECH による TLS 接続の前段階として本物のドメイン名の名前解決が行われますので、DNS Protection にも影響はありません。
ECH による通信の有無の確認方法
お客様の環境で ECH による通信が行われているかどうか、完全ではないものの確認方法はあります。
まずは、ECH のテストサイト にアクセスしてみてください。
“You are using ECH.” と表示されれば ECH で通信が行われおり、”You are not using ECH.” と表示されれば ECH が使われていないことを示します。
また、テストサイト以外での ECH による通信を確認する方法として、Cato の CMA の Events 画面にて “Domain Name” がダミーのドメイン名であるイベントを確認する方法があります。
上記のテストサイトの場合ですと、ダミーのドメイン名は “public.tls-ech.dev” で、イベントには次のような記録が見つけられます。(TLS Inspection を有効にした環境での例で、本物のドメイン名のイベントも合わせて抽出しています。)
上の画像の中でも “Domain Name”, “Sub-Type”, “Action” の3つのフィールドに注目すると、ECH がどのように処理されているかが分かります。
表に書き起こすと次のようになっています。(古い時刻から順に並べ替えています。)
| 時刻 | Domain Name | Sub-Type | Action |
| 2026/03/27 09:44:18.078 | public.tls-ech.dev | Internet Firewall | Monitor |
| 2026/03/27 09:44:18.086 | public.tls-ech.dev | TLS | Alert |
| 2026/03/27 09:44:18.255 | tls-ech.dev | Internet Firewall | Monitor |
まず最初に ECH を用いた TLS 接続が行われたため、Cato ではダミーのドメイン名でイベントが記録されており、Internet Firewall 機能は通過しています。
2つ目のイベントは TLS が Alert となっていますが、これは先ほどの説明の通り、Cato が ECH を処理できないためにクライアント (ブラウザ) が TLS 接続をエラー終了させていることを示しています。
3つ目のイベントは本物のドメイン名で記録されており、ECH を使わない通常の TLS 接続にフォールバックしたことを示しています。
2026年3月現在、ECH が有効な Web サイトは少なく、Cloudflare にホスティングされている Web サイトでしかまだ採用されていないように見受けられます。Cloudflare 上の Web サイトの場合、ダミーのドメイン名は全サイト共通で “cloudflare-ech.com” となっています。
“Domain Name” が “cloudflare-ech.com” であるイベントを確認し、Cato のいずれかのセキュリティ機能でブロックやエラー (Alert) となっていれば、ECH による通信は失敗していると判断できます。
ECH への対策方法
ECH によって Cato のセキュリティ機能が適切に働かない問題への対策方法はいくつか考えられ、現状で取りうる対策を以下に整理します。
1. TLS Inspection を有効にする
先ほどの説明や例の通り、TLS Inspection が有効であれば ECH による通信が失敗しますので、Cato のセキュリティ機能が適切に働きます。
TLS Inspection を有効にしていないお客様ですと、これを有効にすると既存の通信に多大な影響が及ぶため、この方法を採れないかもしれません。しかし、ダミーのドメイン名だけでも TLS Inspection を行うようにすれば ECH の問題を解消できますので、ご検討いただければと思います。
ただし、Cato では一部の OS (Android, Linux, その他不明なOS) の通信では TLS Inspection が行われないようになっていますので、それら OS が行う通信は ECH によってセキュリティ機能が働かないという問題があります。
2. ダミーのドメイン名の通信をブロックする
ダミーのドメイン名の通信を Internet Firewall でブロックするというのも有効な対策です。ひとまず、”cloudflare-ech.com” 宛の通信をブロックすれば、現状では ECH に対策できていると言ってよいかと思います。
ただ、今後は Cloudflare 以外の Web サイトのホスティング事業者も ECH をサポートしてくることが予想されます。その場合、ダミーのドメイン名も事業者ごとに用意されるはずですので、ブロックすべきドメイン名を追加する運用も必要となってくる点に注意が必要です。
3. HTTPS レコードのクエリをブロックする
もしもお客様が独自の DNS サーバをお使いであれば、その DNS サーバにて HTTPS レコードのクエリをブロックするという対策も考えられます。実際に試したわけではありませんが、Active Directory の DNS サーバをお使いであれば、HTTPS レコード (Type 65) をブロックする設定は可能だろうと思います。
ただ、OS やブラウザによっては意図しない DNS サーバを参照することもあるようですので、この方法も完全ではありません。
あとがき
TLS Encrypted Client Hello (ECH) はインターネット標準のセキュリティ技術ではありますが、Cato のようなセキュリティサービスとは相性が悪い困った技術でもあります。
ECH によって引き起こされる問題への対策方法を3つ挙げましたが、1,2 の方法を両方とも採用することが現状での最適な対策と言えるかと思います。
しかし、現在行う対策が将来においても有効であるとは限らないため、Cato にて次のような機能が実装されることを期待しています。
- クライアント OS を区別せず、ECH による TLS 接続を拒否する機能 (対策1の但し書きへの対応)
- ダミーのドメイン名であることを示す Application Category 定義の作成と随時更新 (対策2の但し書きへの対応)
- HTTPS レコードのクエリをブロックする機能（対策3の実現)
ECH は Cato に限らず様々なセキュリティサービスでも同様の問題を引き起こすはずですので、不明点や疑問点などがありましたら何でもご相談いただければと存じます。