プライバシー護衛隊

見過ごされがちな通信プライバシーリスク：TLS/SSL証明書・SNIからの情報漏洩とECHによる技術的対策

Tags: TLS, SSL, SNI, ECH, 通信セキュリティ, プライバシー保護, ネットワーク

デジタル化が進む社会において、オンラインでの通信の大部分は暗号化されています。特にWeb通信においては、HTTPSの普及により、クライアントとサーバー間のデータはTLS/SSLプロトコルによって保護されていることが一般的です。これにより、通信内容そのものが第三者に傍受され、読み取られるリスクは大幅に低減されました。

しかしながら、通信内容が暗号化されていても、通信の確立過程でやり取りされる一部のメタデータからは、プライバシーに関わる情報が漏洩しうるという見過ごされがちなリスクが存在します。本記事では、TLS/SSL通信において特に問題となる「TLS/SSL証明書情報」と「SNI (Server Name Indication)」からの情報漏洩リスクの技術的な側面を解説し、それに対する最新の技術的対策であるEncrypted Client Hello (ECH) について掘り下げます。

TLS/SSL通信確立プロセスと情報漏洩ポイント

HTTPS通信は、まずTCP/IPレベルで接続を確立した後、TLSハンドシェイクというプロセスを経て暗号化された通信路を構築します。このハンドシェイクの初期段階で、いくつかの重要な情報が暗号化されないまま交換されます。

  1. ClientHelloメッセージ:

    • クライアント（ブラウザなど）がサーバーに対してTLS通信の開始を要求する際に送信する最初のメッセージです。
    • このメッセージには、クライアントがサポートするTLSバージョン、暗号スイートのリスト、圧縮方式、拡張機能などが含まれます。
    • そして、複数のウェブサイトを同じIPアドレス/ポート番号でホストしているサーバーに対して、どのサイトへのアクセスを意図しているかを伝えるために、SNI (Server Name Indication) という拡張機能がしばしば使用されます。SNIは、アクセスしようとしているホスト名（ドメイン名）を平文で含みます。これは、サーバーが適切なTLS証明書を選択してクライアントに送信するために不可欠な情報です。
    • このClientHelloメッセージは、TLS通信で暗号化される前の段階で送信されるため、ネットワーク経路上の中間者（例: ISP、社内ネットワークのプロキシ、監視装置など）によって平文で観測可能です。

  2. ServerHelloと証明書送信:

    • サーバーはClientHelloを受け取り、TLSのバージョンや暗号スイートなどを決定し、ServerHelloメッセージを返します。
    • その後、サーバーは自身の身元を証明するために、TLS/SSL証明書をクライアントに送信します。
    • この証明書には、証明書の対象となるドメイン名（Common NameやSubject Alternative Name）、発行者、有効期間、公開鍵などが含まれています。これらの情報も、証明書自体はサーバーの秘密鍵で署名されていますが、データ構造としては公開されており、TLSハンドシェイクの初期段階で平文で送信されます。

TLS/SSL証明書情報とSNIが晒すプライバシーリスク

ClientHello内のSNIや、サーバーから送信されるTLS証明書に含まれる情報は、たとえその後の通信内容が暗号化されていても、以下の形でプライバシーリスクをもたらします。

これらの情報は、従来の通信傍受のように通信内容そのものを把握するものではありませんが、「誰が」「いつ」「どこ（特定のドメイン/サービス）に」アクセスしたかというメタデータは、それ単体でも、あるいは他の情報と組み合わせることで、高度なプライバシー侵害や諜報活動に利用される可能性があります。

従来の対策の限界

TLS/SSL証明書情報やSNIからの情報漏洩に対して、これまでいくつかの対策が試みられてきました。

これらの対策は有効な側面を持ちますが、TLSハンドシェイクの初期段階で漏洩するSNIや証明書情報の根本的な解決には至っていませんでした。

技術的な対策：Encrypted Client Hello (ECH)

SNIやClientHelloメッセージに含まれる情報の平文での露呈という課題に対処するために開発が進められているのが、Encrypted Client Hello (ECH) です。ECHは、TLSv1.3をベースとした拡張機能であり、ClientHelloメッセージ、特にSNIをエンドツーエンドで暗号化することを目的としています。

ECHの仕組みの概要

ECHは、ClientHelloを二つの部分に分割して処理します。

  1. Outer ClientHello:

    • これは平文で送信される部分です。ここには、暗号化されたClientHelloを処理できることを示す情報や、暗号化に必要な鍵情報の一部（公開鍵）などが含まれます。
    • アクセス先のドメイン名としては、SNIの代わりに、そのドメインをホストしているCDNやプロキシサービスの一般的なホスト名（Public Nameと呼ばれる）などが使用されることが想定されています。これにより、中間者には具体的なアクセス先のドメイン名が直接は分かりにくくなります。

  2. Inner ClientHello:

    • これは暗号化される部分です。実際のアクセス先のドメイン名（オリジンサーバーのホスト名、Private Nameと呼ばれる）、本来送信したかった暗号スイート、その他のTLS拡張機能などが含まれます。
    • この部分は、サーバーの公開鍵を使用して暗号化されます。クライアントは、DNSレコード（特にType 65）などから、サーバーのECH公開鍵を事前に取得する必要があります。

サーバーはOuter ClientHelloを受け取ると、含まれている鍵情報などを使用してInner ClientHelloを復号化します。復号に成功すれば、Inner ClientHelloに含まれるPrivate Nameを用いて、本来のアクセス先ドメインに対応する適切なTLS証明書を選択し、以降のTLSハンドシェイクを続行します。

ECHによるプライバシー保護効果

ECHが成功すれば、ネットワーク上の中間者はOuter ClientHelloしか観測できません。Outer ClientHelloのPublic Nameは、実際のアクセス先（Private Name）とは異なるか、より抽象的な情報であるため、中間者はSNIから直接得られるような具体的なアクセス先ドメイン名を把握することが困難になります。これにより、ユーザーのアクセス履歴に基づく詳細なプロファイリングを阻止する効果が期待されます。

ECHの現状と課題

ECHは現在も開発・標準化が進められている比較的新しい技術です（RFC 9147として標準化）。一部のモダンなブラウザ（例: Chrome, Firefox）やサーバー/CDN（例: Cloudflare）では実験的にサポートが始まっていますが、広く普及するには時間を要します。

課題としては、すべてのクライアント、サーバー、そしてネットワークインフラ（ファイアウォール、プロキシなど）がECHに対応する必要がある点が挙げられます。また、Public Nameとして共通のCDNドメインなどが使われる場合、そのPublic Nameへのトラフィックが集中し、別の形でメタデータによるトラフィック分析の対象となる可能性も指摘されています。

まとめ

HTTPSによる通信内容の暗号化はプライバシー保護の基礎ですが、TLSハンドシェイクの初期段階で送信されるSNIやTLS証明書に含まれる情報からは、アクセス先の具体的なドメイン名が露呈し、プライバシーリスクとなることをご理解いただけたかと思います。これらの情報は、ユーザーの行動履歴プロファイリングなどに悪用される可能性があります。

この課題に対する有望な技術的対策として、Encrypted Client Hello (ECH) が開発されています。ECHはClientHelloメッセージ、特にSNIを暗号化することで、中間者によるアクセス先ドメインの特定を困難にします。

ECHの普及はまだこれからですが、このような新しい技術動向を注視し、自身が利用するブラウザやサービスがECHに対応しているかを確認することは、デジタルプライバシーをより高度に保護する上で重要です。私たちは、技術の進化とリスクの変遷を常に追いかけ、適切な自己防衛策を講じていく必要があります。プライバシー護衛隊では、引き続きこうした最新の技術情報を提供してまいります。