この記事で扱うこと
iOS 15から使えるようになった、iCloud Private Relay（プライベートリレー）というベータ版機能について、iOS 15リリース当初に確認した挙動のメモ。
主に、Private Relayの対象となるHTTPの通信について調べており、名前解決については詳しくは扱わない。
TL;DR
iOS 15.0 にて確認した、Private Relayを通る対象となる通信は以下の通り
- Webアクセス時の名前解決（ただし若干、漏れが発生している？）
- Safari によるWebアクセス
- アプリの SFSafariViewController, ASWebAuthenticationSession によるWebアクセス
- アプリの WKWebView, URLRequest による平文HTTP通信
- アプリによる 80/tcp 宛ての通信
他にも対象となる通信があるかもしれないが、あいにくiOSアプリ開発の知見がなく、網羅はできていない、正確性に欠く可能性がある点に注意。
以下、詳細
はじめに
iCloud Private Relayについては、ネットワーク・サーバ管理者向けに書かれたドキュメントがあります。
iCloud Private Relayに向けたネットワークやWebサーバの準備 – サポート – Apple Developer
すでに、おおよそPrivate Relayの対象となる通信について言及されています。
Private Relayは、SafariでのWebブラウジングとDNS解決クエリを保護し、Appの安全でないhttpトラフィックからユーザーを守ります。
https://developer.apple.com/jp/support/prepare-your-network-for-icloud-private-relay/
Private Relay protects users’ web browsing in Safari, DNS resolution queries, and insecure http app traffic.
https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay/
日本語ではアプリによる名前解決が対象となるのか読み取りにくいですが、英語を読む限りは対象となっているようですね。
そこからさらに、細かな挙動を調べてみました。
端末：iPhone 8 Plus iOS 15.0
調査日：2021-09-22 ～ 2021-09-23 ごろ
接続元の事業者としてCloudflareやAkamai、Fastlyという名前が見えれば、それは今回の調査においてPrivate Relayの対象になったことを意味します。transixは私が利用している事業者によるものです。
詳細調査
列挙したPrivate Relay対象の通信のうち、いくつか詳細を説明します。
アプリの SFSafariViewController, ASWebAuthenticationSession によるWebアクセス
Slackアプリの、Googleアカウントでのログイン画面を開いてみました。iOSのショートカットアプリを使うと、開いたSafariView（ここでは認証用のASWebAuthenticationSessionを使用）の上でJavaScriptを実行することができるので、 location.href を変更してみた結果のスクリーンショットです。
Cloudflareなので、Private Relayを通っていますね。
ツイートには含まれていませんが、 SFSafariViewController に関してもPrivate Relayの対象でした。
SafariView系なのかWebView系なのかの見分け方は、以下の公式ドキュメントを見るとわかりやすいかと思います。
Appにおけるウェブビューを実現するには、WKWebViewとSFSafariViewControllerのどちらを使うべきですか – 見つける – Apple Developer
SlackやTwitterアプリなどで見かける、アプリ内ブラウザと呼ばれるようなものは SFSafariViewController でしょう。シンプルなデザインの「進む」、「戻る」、「標準ブラウザで開く」ボタンなどがついているものです。
アプリの WKWebView, URLRequest による平文HTTP通信
Safari以外のアプリ内の、古くからあるいわゆるWebViewである WKWebView による通信を確認してみました。
https:// の宛先にはPrivate Relayは適用されないことが分かっていたのですが、なんと http:// の宛先には適用されました。平文HTTPであれば、いくつか試した限りはどの宛先ポート番号であってもPrivate Relayの対象となりました。
※Rakuten Linkへの言及に関しては憶測なので、ここでは読み飛ばしてください。
WKWebView の例として、開いているブラウザはFirefoxです。
楽天モバイルの回線ですが、 "isp":"Cloudflare, Inc." になっていることが確認できます。
URLRequest を使用しているとみられる、REST APIを叩く開発者向けのデバッグアプリなどでも、やはりPrivate Relayの対象でした。
アプリによる 80/tcp 宛ての通信
Safari以外のアプリで、HTTPに限らない通信をした場合の挙動について確認しました。
iSH ShellアプリでwgetやSSHコマンドを実行した結果としては、 80/tcp 宛てであればPrivate Relayを通っていました。
Firefoxの WKWebView では 8080/tcp でもAkamaiになっているにも関わらず、iSH Shellのwgetコマンドでは同じポート番号でもtransixになっているのが確認できます。iSH ShellでPrivate Relayを通ったのは、 80/tcp 宛てのときのみでした。
-p 80:22 として立ち上げたsshdであるため、 $SSH_CLIENT に含まれる宛先ポート番号は22になっているが、外からの接続に使っているのは80HTTPではない通信のSSHであっても、 80/tcp であればPrivate Relay対象になりました。SSH接続した際の環境変数 $SSH_CLIENT には接続元のIPアドレスが含まれるため、それを確認しています。
IPアドレス 104.28.4.74 だけではパッと見てどの事業者なのかわかりにくいため、そのアドレスがCloudflareであることもあわせて確認し、スクリーンショットに含めました。
80/tcp に関しては iptables のようなものでパケットの通信先を曲げているように思えます。iOSアプリのCharles Proxyを併用していると、No route to hostのようなエラーになることがあります。
TCPの23,25、他SMTP Submissionポートなどは対象とならないようでした。あくまでHTTPを対象にしているように思います。
最後に
このように、現在のiCloud Private Relayの実装では、複数の手段でWebアクセス系の通信をPrivate Relayに流す実装がされているようでした。
ただし、現在はWebRTCを使うとPrivate Relayを通らないなど、ユーザーの本来のIPアドレスそのものが漏れてしまうパターンもあるようです。
Webアクセス時の名前解決に関しては、いくつかPrivate Relay（ODoH）を通らず、漏れてしまっているものがありました。何かしら、バグか条件かがあるのかもしれませんが、今回は詳細調査は行えていません。
初めてiCloud Private Relayのサービスを聞いたときは、単にApple公式のVPNかプロキシ、TORのようなものというだけの認識であまり興味を持っていなかったのですが、各所、モバイルのプロバイダやアプリなどでトラブルが発生していると聞くと、その挙動が気になり、ついiCloud+を契約してしまいました。
あくまで、サービスイン当初の挙動を調べたメモですので、今後も同様の挙動であるかは不明である点など、ご注意ください。