製品・ツール / TOOLS / ANDROID / PRIVACY
Android 17が「ECH」を標準対応 — TLSのSNIを暗号化し、どのサイトに接続したかをネットワーク上で隠す
Googleは2026年8月6日、Android 17(APIレベル37)でTLS拡張「Encrypted Client Hello(ECH)」を標準でサポートすると公表した。従来は平文で送られていたサーバー名表示(SNI)を暗号化することで、同一IPに多数のサイトが同居する環境でも、利用者がどのホスト名に接続したかを途中のネットワーク機器やISPから隠せる。アプリが対象APIを狙う場合、対応ライブラリであれば既定で有効になる。
Googleは2026年8月6日、次期モバイルOS「Android 17(APIレベル37)」で、TLSの拡張機能「Encrypted Client Hello(ECH)」を標準でサポートすると公表した。ECHは、TLSハンドシェイクの最初に平文で送られていたサーバー名表示(SNI: Server Name Indication)を暗号化する仕組みだ。利用者がどのサイトに接続したかという情報が、通信経路上の機器やインターネット接続事業者から見えにくくなる。
ECHとは何か — SNIの平文送信という課題を解く
ウェブ通信で使われるTLSでは、接続の最初にクライアントが「どのホスト名に接続したいか」をSNIとして送る。従来、このSNIは暗号化されずに送られていたため、同じIPアドレスに複数のサイトが同居している環境でも、途中のネットワーク機器やISPが接続先のホスト名を読み取れた。DNSの問い合わせも同様に平文であれば、閲覧先が推測される要因になっていた。
ECHは、TLS 1.3の拡張としてこのSNIを含むClientHello全体を暗号化する。接続先サーバーの公開情報(HTTPSレコードに含まれるECH設定)を事前にDNSで取得し、その情報で暗号化してからハンドシェイクを開始することで、中間者がホスト名を解読できないようにする。ECHに対応していないサーバーに対しては、互換性のための「ECH GREASE」と呼ばれるダミーの拡張を送ることで、対応の有無を外部から指紋採取されにくくする配慮も行われる。
Android 17で何が変わるか — 対象アプリは既定で有効
Googleが公表した開発者向けドキュメントによると、Android 17(APIレベル37)以降では、アプリがAPIレベル37以上を対象(targetSdkVersion 37以上)としてビルドされている場合、利用するネットワークライブラリがECHに対応していれば、ECHは既定で全ドメインに対して有効になる。アプリ側で個別のコード変更をしなくても、ライブラリ側の対応によって自動的にプライバシー保護が働く設計だ。
個別に制御したい場合は、アプリのNetwork Security Config(ネットワークセキュリティ設定)でdomainEncryption要素を使って、ドメインごとにECHを無効化したり強制したりできるとGoogleは説明している。例えば、特定のドメインで問題が起きた場合に一時的に無効化するといった運用が可能になる。
ライブラリがまだECHに対応していない場合でも、アプリが直接プラットフォームAPIを呼び出してECHを利用できる。Googleは、まずNetworkSecurityPolicy.getDomainEncryptionMode()でドメインの暗号化ポリシーを確認し、DOMAIN_ENCRYPTION_MODE_ENABLEDやDOMAIN_ENCRYPTION_MODE_OPPORTUNISTICが返った場合にECH設定を取得して接続するよう呼びかけている。なお、OPPORTUNISTICモードはAndroid 17.1(APIレベル37.1)で非推奨となり、以降は明示的に扱う必要はないとしている。
実装の流れ — DNSでECH設定を取得してから接続する
ECHで接続するには、まず接続先のHTTPSレコード(DNSの新しいレコード種別)を解決して、サーバー側のECH設定を取得する必要がある。Googleは、アプリがシステムのDNSを使っている場合、次の2つの方法のいずれかで取得できると説明している。以下は全てGoogleの公表に基づく内容である。
-
DnsResolver.query APIを使う方法 — カスタムのDNS解決が不要なライブラリであれば、プラットフォームの高レベルAPIである
DnsResolver.queryを使い、TYPE_HTTPSで問い合わせる。このAPIはA/AAAA/HTTPSレコードを並列に取得し、結果をHttpsEndpointとしてまとめて返す。 -
低レベルのDNS問い合わせを自前で行う方法 — 独自のDNS実装を持つライブラリでは、DNSメッセージを自前で構築してHTTPSレコードを取得する。
取得したECH設定を使ってTLS接続を開始し、もしサーバー側の設定が古くてハンドシェイクが失敗した場合、サーバーは新しいECH設定を含むリトライ情報を返すことがある。Googleは、この場合に例外を捕捉して再試行する処理を実装するよう推奨している。
Googleによると、主要なライブラリでの対応も進んでいる。OkHttpとHttpEngine(旧Cronet)でECHサポートが近日中に対応予定だとしている。プラットフォーム標準のSSLSocketFactoryを使っているライブラリでは、ECH GREASEの付与は自動的に処理される。
日本の利用者・開発者への影響
Androidは日本国内でも多くのスマートフォンで利用されており、公衆Wi-Fiや企業ネットワーク、モバイル回線といった多様なネットワーク環境で使われている。ECHが普及すれば、同一のクラウドIPに多数のサービスが同居する現代のウェブにおいて、利用者がどのサービスに接続したかというメタデータがネットワーク上で見えにくくなる。ISPや経路上の機器によるホスト名ベースのトラッキングやフィルタリングの精度は低下し、利用者のプライバシーは高まると期待される。
一方、企業ネットワークでホスト名に基づくアクセス制御やログ収集を行っている組織では、ECHによって可視性が下がることを前提に見直しが必要になる可能性がある。Googleは、ECHがDNS over HTTPS(DoH)やDNS over TLS(DoT)と組み合わさることで、名前解決からTLS接続まで一貫してホスト名を保護できると説明している。開発者は、対象APIレベルを37以上に引き上げる際、利用しているHTTPライブラリがECHに対応しているか、Network Security Configでのポリシーが意図通りかを事前に確認することが求められる。
出典
この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。