iCloud Private Relay、3つのWebKit機能で実IPが漏れる問題
iCloud Private Relayを有効にしていても、Webサイト側へ実際のIPアドレスやDNS情報が届く経路が見つかりました。セキュリティ研究者のTalal Haj Bakry氏とTommy Mysk氏は8月4日、WebKitのDNS prefetch、WebAuthn、WebTransportがプロキシを迂回する検証結果を公開しました。ただし、Safariの通信すべてが無防備になる問題ではありません。
3つの処理が通常のリレー経路を外れる
DNS prefetchは、ページが後で使うドメインを先に名前解決する仕組みです。研究者によると、この問い合わせは端末の通常のDNS経路へ出るため、Private Relay利用中でも実際のDNSサーバーが相手へ見えます。WebAuthnのRelated Origin Requestsでは、パスキーの関連ドメインを確かめる通信をOSの認証サービスが直接送り、実IPが露出します。WebTransportもQUIC接続を端末から直接開くため、同じ結果になるとしています。
Appleの説明では、Private RelayはSafariの通信を二つのリレーへ分け、接続元と閲覧先を一社が同時に把握できないようにします。今回の3経路は、その標準的なページ読み込みの外で動く処理です。Private Relayそのものが停止したのではなく、保護対象から外れる通信がWebKitに残っていた、というのが正確です。
Private RelayはVPNではない
影響するのはiCloud Private Relayだけではありません。WebKitのプロキシ設定を使うiOS・macOS向けブラウザにも同じ迂回が起こり、研究者はiOSのTorブラウザにも影響しうると説明しています。一方、端末全体の通信をトンネルへ通すVPNは、今回の問題の対象外です。研究者自身のブラウザPsyloは、DNS prefetchを遮断し、WebAuthnとWebTransportを初期状態で無効にする更新を出しました。
Private Relayの表示がオンでも、ブラウザが始める全通信が同じ経路を通るとは限りません。Appleから修正内容が公表されるまでは、Private Relayをシステム全体のVPNではなく、Safariの通常のWeb通信を守る機能として理解する必要があります。
関連記事
スイッチはオンでも、通信経路は一つではありません。パスキーや高速通信の裏で別の経路が開けば、保護の表示と実際の境界がずれます。WebKitの修正と同時に、その境界をユーザーへどう見せるかもブラウザの設計課題です。