Android 17でネットワークプライバシーに関わる最も大きな変更の一つが、**Encrypted Client Hello(ECH)**へのプラットフォーム対応です。ECHはTLS 1.3の拡張機能で、安全な接続の開始時に通常は露出していた接続先ホスト名を暗号化します。これにより、Wi-Fiの管理者やインターネットプロバイダーなどが、アプリの接続先をホスト名から特定しにくくなります。ただし、完全な匿名化を実現する機能ではありません。 46
ECHの保護が実際に働くには、端末がAndroid 17以降であること、アプリがECH対応のネットワークライブラリを使っていること、接続先サービスがECHを導入していることが必要です。 25
ECHが暗号化するもの
通常のTLS接続では、クライアントが接続したいホスト名を**Server Name Indication(SNI)**として送信します。ECHは、TLS接続開始時のClientHelloに含まれるこの機密性の高い部分を、接続先サービスが公開する設定情報と鍵を使って暗号化します。サーバーは保護された情報を復号できますが、ネットワーク上の監視者に見えるのは、目的のホスト名を含まない外側のハンドシェイクです。 416
HTTPSはもともと通信内容を暗号化していますが、接続先のホスト名が分かれば、どのサービスを利用しているかを推測できる場合があります。ECHは、このTLSハンドシェイクにおけるホスト名の漏えいを、対応する接続先に対して抑えるための仕組みです。 56
それでもネットワークから見える情報
ECHは、接続に関わるすべての情報を隠すわけではありません。監視者の位置や接続条件によっては、次のような情報が引き続き確認できる可能性があります。
- 端末の送信元IPアドレス
- 接続先IPアドレス。CDNやホスティング事業者を示したり、場合によっては特定のサービスを推測できたりします
- 通信のタイミング、パケットサイズ、通信量
- DNS問い合わせを別途保護していない場合の名前解決情報
そのため、ECHをVPNや匿名化システムと表現するのは正確ではありません。Googleは、ECHとPrivate DNSを補完的な保護として説明しています。ECHはTLSハンドシェイク内のホスト名を隠し、暗号化DNSは別途行われるドメイン名の問い合わせを保護します。どちらも端末のIPアドレスそのものを隠す機能ではありません。 612
Android 17でECHが使われる条件と既定動作
Android 17には、ネットワークライブラリがECHを実装するためのOS側のサポートとAPIが用意されています。ECH設定を含むHTTPS DNSレコードを取得するための機能も含まれます。 4
ただし、実際にECHが使われるには次の3条件がそろわなければなりません。
- 端末がAndroid 17以降であること
- アプリのネットワーク処理系がECHに対応していること。Androidのドキュメントでは、HttpEngine、WebView、OkHttpなどが例として挙げられていますが、OSが対応しただけで、すべてのライブラリが自動的にECH対応になるわけではありません。 23
- 接続先サーバーがECHを導入していること。サーバー側の設定がなければ、クライアントは接続先ホスト名をECHで暗号化できません。 25
Android 17以降をターゲットにするアプリでは、ネットワークライブラリと接続先サーバーの双方がECHに対応している場合、TLS接続でECHが使われます。ECHを利用できない場合に接続を続行するのか、それとも接続を失敗させるのかは、アプリが設定したドメイン暗号化ポリシーによって決まります。 12
ECH GREASEとは
Androidのドメイン暗号化ポリシーは、ECHを単純に「使う/使わない」で切り替えるだけではありません。ドメイン暗号化が有効で、接続先が実際のECHに対応していない場合、AndroidはECH GREASEを送信できます。これは機能しない意図的な拡張ですが、ECHに似た通信として扱われます。
目的は、互換性を保ち、単純な通信分類を難しくすることです。ネットワークやサーバーが「ECHが使える接続なら必ずECHらしい通信があり、使えない接続なら一切試みない」と判断しにくくなります。ただし、GREASEは成功したECHと同じようにホスト名を隠すものではありません。サーバー側の導入に代わる機能でもなく、互換性のための仕組みです。 1
アプリがドメイン暗号化を無効にしている場合、AndroidのNetworkSecurityPolicyのドキュメントでは、ECHもGREASEも使用すべきではないとされています。同APIでは、ドメイン暗号化を有効にする設定や、ECHを必須にして利用できなければ接続を失敗させる設定も扱えます。 1
開発者に必要な対応
Android 17に対応しただけで、すべてのアプリの通信が自動的にECHで保護されるわけではありません。開発者は、少なくとも次の点を確認する必要があります。
- 利用中のネットワークライブラリがAndroid上のECHに対応しているか確認する。 235
- Network Security Configなどで、アプリのドメイン暗号化ポリシーを設定する。 15
- 接続先サービスが公開するECH設定を、ライブラリが取得して利用できることを確認する。Androidには、ECH設定を含むHTTPS DNSレコードを取得するためのプラットフォームAPIがあります。 4
- ECH対応サーバーと非対応サーバーの両方でテストし、フォールバックを許可するのか、ECHを必須にして利用できない場合は接続を停止するのかを決める。 1
サーバー運営者側もECHを導入し、クライアントが必要とする設定を公開しなければなりません。このサービス側の対応が必要なため、Android 17のプラットフォーム対応だけで、すべてのアプリの接続先ホスト名がすぐに隠れるわけではありません。 516
Googleは、Jigsaw、業界関係者、サービスプロバイダー、アプリ開発者と協力し、ECHの採用拡大に取り組んでいると説明しています。特別な設定をしたブラウザーだけでなく、共通のネットワーク基盤を通じてアプリでもホスト名を保護できるようにすることが、より大きな狙いです。 46
Android 17に加わるその他のネットワーク保護
ローカルネットワークへのアクセスに実行時権限
Android 17以降をターゲットにするアプリは、ローカルネットワーク上のデバイスを検出したり接続したりする前に、ACCESS_LOCAL_NETWORKの実行時権限を要求する必要があります。この権限は既存のNEARBY_DEVICESグループに含まれるため、すでに同グループの別の権限を許可しているユーザーには、グループ単位で新たな確認画面が表示されない場合があります。 217
この変更は、アプリがユーザーに気付かれないままローカルネットワークをスキャンし、追跡やフィンガープリント採取、脆弱な機器の探索に利用することを抑える狙いがあります。スマートホーム機器やキャストレシーバーなど、LAN上のデバイスに正当に接続するアプリは、権限を宣言してリクエストする必要があります。 1719
Certificate Transparencyをデフォルトで有効化
Android 17では、**Certificate Transparency(CT)**がTLS接続でデフォルト有効になります。CTは、公開TLS証明書を公開性のある監査可能なログに記録させることで、不適切に発行された証明書を発見しやすくする仕組みです。アプリはネットワークセキュリティ設定を通じて、全体または特定ドメイン単位でオプトアウトできます。 3
キャリアが安全性の低い2G接続を制限可能に
Android 17には、セキュリティの弱い2G携帯通信に関する保護も追加されます。対応する端末や通信事業者では、キャリアが2G接続をデフォルトで制限または無効化できるようになり、不正な基地局やSMSブラスタ攻撃への露出を抑えます。具体的な動作は、キャリアと端末の対応状況によって異なります。 8
結論:ECHは「見えなくする」のではなく「見えにくくする」
ECHは、クライアントとサーバーの双方が対応している場合、TLSハンドシェイクの重要な部分からホスト名を取り除く意味のあるプライバシー改善です。しかし、ウェブ閲覧を完全に不可視にするものではありません。DNS設定、接続先IPアドレス、通信時間、パケットサイズ、通信量などから、なお手がかりを得られる可能性があります。
ドメイン名のプライバシーを高めるには、ECHを暗号化DNSと組み合わせるのが有効です。IPアドレスまで隠したい場合は、VPN、プロキシ、Torなど別の仕組みが必要になります。
Android 17の変更を最も正確に表すなら、こうです。ネットワーク監視者がウェブサイトやサービス名を読み取りにくくする一方、接続に伴うほかのメタデータまではECHの保護範囲に含まれない、ということです。