さて!答えを予想してみましょう!
実験1
iOS 15もしくはiPadOS 15において,以下の2つのブラウザ
- Safari
- Firefox Focus
- App Storeから入手可能です
で以下の3つのサイト
- kiriwake jpne
- cman cgi
- test-ipv6
を覗いた時,対応するプロバイダ(もしくはそれが十分に類推できるiPアドレス)が以下のように表示された.
Safari | Firefox Forcus | ||||||
kiriwake jpne | cman cgi | test-ipv6 | kiriwake jpne | cman cgi | test-ipv6 | ||
Private Relay enable | v6+ | egress node | egress node | egress node | egress node | jpne vne | jpne vne |
4G LTE | egress node | egress node | egress node | egress node | docomo sp | docomo sp | |
Private Relay disable | v6+ | jpne vne | |||||
4G LTE | docomo sp |
ここでdocomo sp(spmode-ne.jp)の場合は必ずipv4接続のみが表示された.
egress nodeはiCloud+のPrivate Relay出口ノード(プロキシ?サーバ?)であり,Fastly・Cloudflare・Akamaiのいずれかがランダムに出現する.
考察1-1
AppleによるPrivate Relayの説明によれば,
iCloud+ のサブスクリプションで使える iCloud プライベートリレーは、Safari で Web を閲覧する際にプライバシーを守ってくれます。詳しくご説明します。
Private Relayは、SafariでのWebブラウジングとDNS解決クエリを保護し、Appの安全でないhttpトラフィックからユーザーを守ります。
Safariでのブラウズ時、Private Relayはユーザーのデバイスから発信されるすべてのトラフィックを確実に暗号化し、Appleやユーザーのネットワークプロバイダを含む何者もユーザーと訪問先のウェブサイトの間でのトラフィックにアクセスしたり読み取ったりできないようにします。
とあることから,Safari(又はSFSafariViewController系)ではないはずのFirefox Focusで接続した時にPrivate RelayのEgress Nodeの情報が表示されたkiriwake jpneの挙動は『この説明には』則していないと言える.
現にこうやって表示された以上,何らかの干渉が発生していると見るべきでは?
考察1-2
kiriwake jpneについて解説するページがjpneからお出しされていたが,
なお、以下の状況では、JPNE切り分けサイトによるチェックが失敗する可能性があるので注意が必要です。
Google Chromeのライトモード(GoogleのProxy経由)がON
Cloudflare WARPなどのVPNが設定されていた
上記状況では、JPNE切り分けサイトとの接続がプロキシ経由になります。このとき、HTTPなどによってJPNE切り分けサイトと直接接続するのはプロキシです。
そのため、JPNE切り分けサイトのチェックで、v6プラスを利用していないと判定されてしまいます。
確かにSafariなら説明の通りの挙動をするものの,Private Relayの対象外であるはずのFirefox Focusでこの挙動をする説明には至っていない.
ページのソースを見ても,jpne.co.jpがこちらのipv6アドレスを把握してページをレンダリングしてから.cgiファイルを送ってきているように見える.
推察1-1
もしかして…ipv6接続が優先されるサイトの場合,ブラウザがSafariかどうかに関わらず,強制的にPrivate Relayを経由するようになる…とか?
追加実験1
nslookup kiriwake.jpne.co.jp
で得られた18.179.181.47
でアクセスしてみた,これを叩くと強制的にipv4接続になり,トップにipv4アドレスが表示される
…ダメです,出口串のIPアドレスが出ました,結果もさっきと変わらなかったです
追加実験2
iPadOSで同じことをやったらiOSと同じ結果になった,これは一体…
推察1-2
なぜかkiriwake.jpne.co.jpとPrivate RelayとFirefox Focusだけ相性が悪いとしか言いようがない
実験2
他のサイトでもやってみたり,パケット覗き見したりする必要があると思いましたので,お時間を下さい
先駆者の方がいらっしゃいました,これはありがたい…
解決
Appの安全でないhttpトラフィックからユーザーを守ります。
この「App」は「Safariだけ」ではなく**「App全体」を指す**.
すなわち
- 端末から出るTCP80宛の通信
- WKWebViewから出るHTTPプロトコルの通信
- SafariおよびSFSafariViewControllerから出る通信
が対象となり,上記の3サイトの中でkiriwake jpneのURLだけが非httpsであったため,Firefox Focusと言えどPrivate Relayに通信を流さざるを得なかったという流れになる.
もちろん当該サイトはhttpsでも実装されているので,つまり「なぜかhttpでurlを生成して実験した私が悪い」という表現が正確だと言えるだろう.う〜んこの
この辺はOS側で通信をチェックしているようで,非httpsやTCP80宛の通信Chromeでも何でもPrivate Relayへと流される.
実際にやってみたら本当にそうなった,端末から見えちゃうくらいなら隠せというAppleの思想なんだろうか…?
感想
macOS Montereyが正式リリースされ次第でそっちでも確認したいですけど,誰かにこれと同じことを試してみて欲しいと思っています…
実際の検証を元に教えて頂いた方,本当にありがとうございます🙏↓
https://twitter.com/falms