Android 17がHTTPSのプライバシーを強化―ECHで通信事業者から接続先を見えにくく

2026年8月30日 23:39

Googleは2026年8月27日、Android 17に導入した4つのネットワーク関連のプライバシー・セキュリティ機能を発表した。中心となるのは、HTTPS接続時に宛先ドメインを保護する「Encrypted Client Hello（ECH）」へのOSレベルでの対応だ。

ECHは対応するアプリ、通信ライブラリ、接続先サーバーの間で機能する。Android 17へ更新しただけですべての通信先が隠れるわけではないが、ブラウザ以外のアプリにも保護を広げる基盤が整った。あわせて、2Gを悪用する偽基地局への対策、ローカルネットワークへのアクセス制限、Certificate Transparencyの標準化も進められた。

■HTTPSでも見えていた接続先ドメイン

HTTPSは、ウェブサイトやアプリとサーバーの間で送受信される内容を暗号化する。しかし従来の一般的なTLS接続では、暗号化通信を始める前の「ClientHello」と呼ばれるメッセージに、接続先ホスト名を示すServer Name Indication（SNI）が平文で含まれていた。

SNIは、1つのIPアドレスで複数のウェブサイトを運用する際に、サーバーが適切な証明書や接続先を選ぶために使われる。通信内容がHTTPSで暗号化されていても、通信経路上のISPやモバイル通信事業者、Wi-Fiネットワークの管理者などは、この情報から接続先ドメインを把握できる場合があった。

米連邦取引委員会（FTC）が2021年に公表した大手ISP 6社に関する調査では、対象企業が閲覧履歴、アプリ利用状況、位置情報などを収集し、広告や顧客分析に利用していた実態が報告されている。ドメイン情報を保護することは、通信内容だけでなく、利用者の行動を推測できるメタデータを減らす意味を持つ。

■ClientHelloを暗号化するECH

ECHは、TLS接続の冒頭で送られるClientHelloの機密性が高い部分を暗号化する仕組みで、2026年3月にRFC 9849として標準化された。SNIだけでなく、アプリケーション層で使用するプロトコルの候補を示すALPNなども保護対象となる。

ECHでは、実際の接続先などを含む「内側」のClientHelloを、サーバー側が公開する鍵を使って暗号化する。その暗号化データを、外部から見える「外側」のClientHelloに格納して送信する。通信経路上の第三者からは、実際の接続先ではなく、ECHサービスの公開名などが見える構造だ。

この仕組みが有効に働くには、クライアント側だけでなく接続先のサーバーもECHに対応し、必要な設定情報をDNSのHTTPSレコードなどで公開する必要がある。

また、DNS問い合わせが暗号化されていなければ、TLS接続より前の名前解決からドメインが分かる可能性がある。Googleは、ECHとプライベートDNSを組み合わせることで、DNS問い合わせとTLSハンドシェイクの双方から接続先情報が漏れる可能性を減らせるとしている。

■Android 17では対応アプリで標準有効

Android 17では、ECHがプラットフォームレベルで利用できるようになった。Android 17を対象に開発され、ECH対応のネットワークライブラリを使用するアプリでは、ECHが標準で有効になる。

対応ライブラリには、新しいバージョンのOkHttp、WebView、GoogleのHttpEngineなどが含まれる。接続先サーバーもECHに対応していれば、実際のホスト名を含むClientHelloが暗号化される。

一方、独自の通信処理を実装しているアプリや、ECHに対応していないライブラリを使用するアプリでは、Android 17上でも自動的に保護が適用されるとは限らない。利用者側でECHの使用状況を一律に制御するというより、アプリ開発者とサービス提供者の対応によって保護範囲が広がる仕組みである。

Android 17は、ブラウザごとの実装に限られていたECHをアプリの通信にも広げやすくした点に意義がある。Googleは、主要なモバイルOSとして初めて、ECHをプラットフォーム全体に広く導入したとしている。

■ECH GREASEで互換性と普及を支える

Android 17では「ECH GREASE」も標準で使用される。GREASEは、将来のプロトコル拡張が既存のネットワーク機器によって拒否される状態を防ぎ、ECHに対応している接続だけが不必要に目立つことを抑えるための仕組みだ。

接続先がECHに対応していない場合、クライアントは実際には使われないECH形式の拡張情報を送ることがある。この場合、接続先ホスト名そのものは保護されないが、ネットワーク機器が未知の拡張情報を許容できるかを継続的に確かめ、ECHの導入を妨げる互換性問題を減らせる。

Googleのインターネット安全部門Jigsawは、世界の上位1万ドメインを対象とした接続試験に加え、202カ国の740のISPを経由する試験を実施した。GoogleとJigsawによると、通常のTLSと比べて接続成功率の低下は確認されず、ネットワークによる干渉もほぼ確認されなかったという。

これらはJigsawによる測定結果であり、世界中のすべてのアプリ、サーバー、ネットワーク構成で障害が生じないことを保証するものではない。ただし、大規模な導入に向けてECH GREASEの互換性を確認する材料となった。

■ECHで見えにくくなる情報と残る情報

ECHが主に保護するのは、TLSハンドシェイクに含まれるSNIなどのClientHello情報だ。HTTPSで送受信される本文を暗号化するTLS本来の機能を補い、接続開始時に見えていたドメイン情報を保護する。

一方、接続先のIPアドレス、通信量、接続時刻などはネットワークから引き続き観測できる。1つのIPアドレスを多くのサイトが共有するCDNでは、IPアドレスだけから個別のドメインを特定しにくい場合があるものの、接続先サービスを推測できるケースは残る。

ECHはVPNとも役割が異なる。VPNを利用すると、端末とVPNサーバーの間の通信はトンネル内で暗号化され、端末側のISPやWi-Fi運営者からは、その内側にある接続先ドメインや宛先IPアドレスが通常は見えなくなる。一方、VPNサービスの運営者やVPN出口以降の通信経路では、ECHが使われていないTLS接続のSNIなどを観測できる可能性がある。

ECHは実際の接続先ホスト名をClientHello内で暗号化し、VPNは端末からVPNサーバーまでの通信経路をまとめて保護する。プライベートDNSはDNS問い合わせを暗号化する。それぞれ保護する場所と情報が異なり、必要に応じて組み合わせる関係にある。

■企業ネットワークでは管理方針の確認が必要

企業や学校などの管理ネットワークでは、ファイアウォールがSNIを読み取り、アクセス先の制限や不正通信の検知に利用することがある。ECHによって実際のSNIが暗号化されると、従来のSNIベースの監視やフィルタリングはそのままでは機能しにくくなる。

Android 17には、管理対象環境においてDNS設定を通じてECHの動作を制御する仕組みが用意されている。Android 17端末を配備する企業のIT管理者は、既存のプロキシ、ファイアウォール、DNS管理、コンプライアンス要件との整合性を確認する必要がある。

■通信事業者が2Gを標準で無効化可能に

Android 17では、参加するモバイル通信事業者が加入者端末の2G接続を標準で無効化できるようになった。Android 12以降には利用者が2Gを手動で無効化する機能があるが、新しい仕組みでは通信事業者側から初期設定として適用できる。

対策の対象となるのは、「SMSブラスター」などと呼ばれる偽基地局を使った攻撃だ。攻撃者は端末を4Gや5Gからセキュリティ機能の弱い2Gへ誘導し、正規の通信事業者のネットワークを通さずに、偽のSMSを端末へ送信することがある。

こうしたメッセージは、通信事業者側の迷惑メッセージ検知を通過しないため、配送業者や金融機関などを装ったフィッシングに悪用される可能性がある。2G接続自体を無効にすれば、この方式で端末を偽基地局へ接続させる攻撃経路を減らせる。

実際に自動無効化が適用されるかどうかは、端末の対応状況や通信事業者の参加に左右される。Googleは発表時点で、参加する通信事業者の一覧や日本国内での提供状況を明らかにしていない。

■ローカルネットワークへのアクセスを制限

Android 17を対象とするアプリでは、ローカルネットワークへのアクセスが標準で制限される。家庭や職場のWi-Fiに接続したアプリが、同じネットワーク上にあるテレビ、プリンター、ゲーム機、カメラなどを探索したり、直接接続したりするには、原則として利用者の許可が必要になる。

広範かつ継続的なアクセスが必要なアプリは「ACCESS_LOCAL_NETWORK」権限を使用する。動画をテレビへキャストする場合など、特定の機器だけを一時的に選択すればよい用途では、Androidが提供するプライバシー保護型の機器選択インターフェースを利用できる。

これにより、アプリにネットワーク全体を探索する権限を与えず、利用者が選んだ機器との通信だけを許可できる。ローカルネットワーク上の機器構成が、端末識別や利用環境の推測に使われる可能性を抑える狙いがある。

■Certificate Transparencyも標準で有効

Android 17を対象とするアプリでは、Certificate Transparency（CT、証明書の透明性）が標準で有効になる。Android 16では開発者が個別に有効化する方式だったが、Android 17では対応アプリに標準適用される。

CTは、認証局が発行したTLS証明書を公開された追記型ログに記録し、ドメイン所有者や監視サービスが不審な証明書を発見できるようにする仕組みだ。認証局による誤発行や侵害が起きた場合でも、証明書が公開ログに残ることで検出しやすくなる。

CTそのものが不正な証明書を自動的に失効させるわけではない。公開ログによる監査可能性を高め、誤発行の検出と、その後の失効や調査につなげる役割を担う。

■開発者に求められる対応

アプリ開発者は、Android 17を対象としたうえで、ECHに対応する新しいネットワークライブラリを使用する必要がある。OkHttp、WebView、HttpEngineなどを利用する場合も、使用中のバージョンとECH対応状況を確認することが重要だ。

サービスやウェブサイトの運営者側では、サーバーのECH対応と、クライアントが設定情報を取得するためのDNSレコードが必要になる。アプリがECH対応ライブラリを使っていても、接続先サーバーが対応していなければ、実際のホスト名は暗号化されない。

Android 17による変更は、ECHを端末上の一部ブラウザだけの機能から、対応アプリ全体へ広げるための基盤となる。実際の保護範囲は、今後のアプリ、通信ライブラリ、サーバー、通信事業者による対応の広がりによって決まる。

■注目ポイントQ&A

●Android 17に更新すれば、通信事業者から接続先を完全に隠せますか？

いいえ。ECHに対応するアプリとネットワークライブラリを使用し、接続先サーバーもECHに対応している場合に、TLSハンドシェイク内の実際のホスト名が保護されます。IPアドレス、通信量、接続時刻などは引き続き観測可能です。DNS問い合わせからドメインが分かることを防ぐには、暗号化DNSも必要です。

●利用者がECHを手動で有効にする必要はありますか？

対応するアプリでは標準で有効になります。ただし、アプリがAndroid 17を対象としていること、ECH対応の通信ライブラリを使用していること、接続先サーバーがECHに対応していることが必要です。アプリを最新の状態に保つことは、開発者による対応を端末へ反映するうえで役立ちます。

●ECHはVPNの代わりになりますか？

いいえ。ECHはTLSハンドシェイク内の接続先ホスト名などを保護し、VPNは端末とVPNサーバーの間の通信をまとめて暗号化します。保護する場所と情報が異なるため、利用目的に応じて併用できます。

●ECH GREASEを使えば、すべての通信が同じに見えるのですか？

通信全体が完全に同じ形になるわけではありません。ECH GREASEは、ECHを使えない接続にもECH形式の拡張情報を加えることで、未知のTLS拡張をネットワーク機器が拒否する状態を防ぎ、ECH対応接続だけが単純に識別されることを抑える仕組みです。

●Android 17はSMSブラスターを自動的に防ぎますか？

参加するモバイル通信事業者は、加入者端末の2G接続を標準で無効化できます。実際に適用されるかどうかは、端末と通信事業者の対応状況によります。日本の通信事業者による参加状況は、Googleの発表では明らかにされていません。

●家庭内LANを使うアプリは動かなくなりますか？

一律に利用できなくなるわけではありません。Android 17を対象とするアプリは、広範なローカルネットワークアクセスについて利用者の許可を求めるか、Androidが提供する機器選択インターフェースを使用する必要があります。キャストやプリンター接続などでは、権限の確認画面や機器選択画面が表示される可能性があります。

元記事: Android 17 Hides Your Browsing Destinations From Carriers, Closing HTTPS Privacy Gap

関連記事

最新記事