ECHプロトコル
ベータECHはEncrypted Client Hello ↗の略です。これは、トランスポート層セキュリティ(TLS)の文脈におけるプロトコル拡張です。ECHはハンドシェイクの一部を暗号化し、TLSセッションを交渉するために使用されるサーバー名インディケーション(SNI)をマスクします。つまり、ユーザーがECHが有効なCloudflareのウェブサイトを訪れると、仲介者はCloudflare上のウェブサイトを訪れていることは確認できますが、どのウェブサイトかを特定することはできません。
ECHは、特定のユーザーがあなたのウェブサイトを訪れているという情報へのアクセスを制限し、インターネットサービスプロバイダー(ISP)などの仲介者と不必要に共有されないようにします。ECHを使用することで、ユーザーがあなたのウェブサイトにアクセスする際の訪問に関する具体的な詳細がネットワーク仲介者に漏れなくなります。
通常のTLSハンドシェイク ↗では、クライアントがサーバーにClientHelloメッセージを送信してTLSセッションを開始します。このメッセージには、サポートされている暗号アルゴリズムのリスト、TLSバージョン、要求されたサーバー名(クライアントが接続したいウェブサイトのドメイン名)などの重要な情報が含まれています。サーバー名はサーバー名インディケーション(SNI)を通じて示されます。
ECHでは、ClientHelloメッセージの一部が2つの別々のメッセージに分割されます:内側の部分と外側の部分です。外側の部分には、使用する暗号やTLSバージョンなどの非機密情報と「外側のClientHello」が含まれています。内側の部分は暗号化されており、「内側のClientHello」が含まれています。
外側のClientHelloには、ユーザーがCloudflare上の暗号化されたウェブサイトを訪れようとしていることを示す共通名(SNI)が含まれています。私たちは、Cloudflare上のすべてのウェブサイトが共有するSNIとしてcloudflare-ech.comを選びました。Cloudflareがそのドメインを管理しているため、そのサーバー名のTLSハンドシェイクを交渉するために必要な証明書を持っています。
内側のClientHelloには、ユーザーが訪れようとしている実際のサーバー名が含まれています。これは公開鍵を使用して暗号化され、Cloudflareのみが読み取ることができます。ハンドシェイクが完了すると、ウェブページは通常通りに読み込まれ、他のTLS経由で読み込まれるウェブサイトと同様になります。
実際には、これは、あなたのトラフィックを見ている仲介者が、通常のTLSハンドシェイクを単に見ることを意味しますが、1つの注意点があります:Cloudflare上のECH対応サーバー名へのトラフィックはすべて同じに見えます。すべてのTLSハンドシェイクは、実際のウェブサイトではなく、cloudflare-ech.comのウェブサイトを読み込もうとしているように見えます。
以下の例では、ユーザーがexample.comを訪れています。ECHがない場合、仲介ネットワークはユーザーがアクセスしているウェブサイトを検出できます。ECHがある場合、表示される情報はcloudflare-ech.comに制限されます。
flowchart LR
accTitle: ECHの有無による仲介者の視界
accDescr: この図は、ECHの有無による仲介者の視界を説明しています。
A(ユーザーが<code>example.com</code>を訪問)
A -- ECHあり --> C(仲介者は<code>cloudflare-ech.com</code>を見る)-->B(Cloudflare)
A -- ECHなし --> D(仲介者は<code>example.com</code>を見る)-->B(Cloudflare)
ECHプロトコル技術の詳細については、私たちの入門ブログ ↗を参照してください。
ECHを有効にするには、SSL/TLS > Edge Certificates ↗に移動し、**Encrypted ClientHello (ECH)**を有効にします:
- Cloudflareダッシュボード ↗にログインします。
- アカウントとゾーンを選択します。
- SSL > Edge Certificatesに移動します。
- Encrypted ClientHello (ECH)の設定をEnabledに変更します。
一部のエンタープライズまたは地域のネットワークは、ネットワークを通過するトラフィックに対して監査またはフィルタリングポリシーを適用する必要があるかもしれません。これらのポリシーは、IPアドレスではなくドメイン名の観点で表現されます。したがって、個々のドメイン名に対するAおよびAAAAクエリに応じて、ローカルDNSリゾルバーで適用するのが最適です。
ただし、DNSベースのフィルタリングが適用できない設定の場合、ネットワークは既存のフィルタリングメカニズムが期待通りに機能し続けるようにECHを無効にする2つの方法があります。
最も信頼性の高い方法は、ローカルまたは再帰的DNSリゾルバー自体を介して、クライアントに返されるHTTPSリソースレコードからECH設定を削除することです。あるいは、好ましくは、HTTPSクエリに対して「エラーなし、応答なし」またはNXDOMAIN応答を返すことです。これにより、クライアントはECHを使用するために必要な情報を取得できなくなります。HTTPSリソースレコードを変更すると、DNSSEC検証を行うクライアントに障害が発生する可能性があるため、HTTPS応答を削除することが好ましいアプローチかもしれません。これにより、ChromeなどのブラウザがECHを使用するのを防ぎます。
ECHを無効にする2つ目の方法は、ネットワークカナリアドメインを介して行います。特に、ネットワークのDNSリゾルバーは、use-application-dns.net カナリアドメイン ↗に対するクエリに対して「エラーなし、応答なし」またはNXDOMAIN応答を返すことができます。これにより、FirefoxなどのブラウザがECHを使用するのを防ぎます。詳細については、Firefoxのよくある質問ページ ↗を参照してください。