ハイライト
iCloud プライベート リレーは、ネットワークとサーバーがデュアル プロキシ アーキテクチャを通じてユーザーのインターネット アクティビティを追跡するのを防ぐ iCloud+ の組み込みサービスです。開発者はコードを変更しなくても自動的に恩恵を受けることができますが、サーバーがユーザーの場所と ID を推測するために IP アドレスに依存しないようにする必要があります。
主要内容
Private Relay が登場する前、プライバシーの抜け穴はどこにありましたか?
コーヒーショップで公衆 Wi-Fi に接続し、アプリを開きます。この時点で、DNS クエリは平文で送信されるため、Wi-Fi オペレーターはユーザーがどのドメインにアクセスしたかを知ることができます。この情報は、あなたのオンライン習慣を把握するのに十分です。
さらに深刻な問題は、ターゲット サーバーが実際の IP アドレスを認識できることです。これにより、サーバーは、たとえ Safari のスマート アンチトラッキングが Cookie の関連付けをブロックしたとしても、ユーザーのおおよその位置を推測し、IP アドレスを介してさまざまな Web サイト間でユーザーの ID を関連付けることもできます。
Private Relay のデュアルエージェント アーキテクチャ
Apple の解決策は、2 つの別個のプロキシ サーバーを導入することでした。最初のプロキシは Apple によって運営され、2 つ目はコンテンツ プロバイダーによって運営されます。
主要な設計: ユーザーの IP アドレスとアクセス先のドメイン名の両方を知ることは誰にもできません。 Apple はあなたが誰であるかを知っているだけで、あなたが何にアクセスしているかは知りません。 2 番目のエージェントは、あなたが何にアクセスしているかを知っているだけで、あなたが誰であるかは知りません。
(02:53)
どのトラフィックがプライベート リレーを通過するか
iOS 15 および macOS 12 では、プライベート リレーは次のものに自動的に適用されます。
- Safari でのすべての Web ブラウジング
- すべての DNS ドメイン名解決クエリ
- アプリ内の安全でない HTTP トラフィック (TCP ポート 80)
次のトラフィックは影響を受けません。
- ローカルネットワーク接続
- プライベートドメイン接続
- VPN またはプロキシを使用したネットワーク拡張トラフィック
(04:15)
詳細
コードでプライベート リレーのステータスを検出する
プライベート リレーを有効にするために追加のコードは必要ありませんが、モダン ネットワーク API を通じて接続がプロキシされているかどうかを確認できます。
URLセッションモード:
let task = URLSession.shared.dataTask(with: url) { data, response, error in
// 任务完成后检查 metrics
}
task.metrics { metrics in
for metric in metrics.transactionMetrics {
if let proxy = metric.proxyConnection {
print("连接使用了代理: \(proxy)")
}
// 检查是否使用了 Private Relay
if metric.isProxyConnection {
print("此请求经过 Private Relay")
}
}
}
task.resume()
キーポイント:
transactionMetrics各ネットワークリクエストの詳細なメトリクスを含む配列isProxyConnectionリクエストがプロキシされるかどうかを識別します- リクエストの完了後に正確なメトリクス データを取得する必要がある
Network.framework メソッド:
import Network
let connection = NWConnection(host: "example.com", port: 443, using: .tls)
connection.start(queue: .global())
connection.stateUpdateHandler = { state in
switch state {
case .ready:
if let report = connection.currentPath?.availableInterfaces {
// 检查连接建立报告
}
default:
break
}
}
キーポイント:
NWConnection下位レベルのネットワーク接続制御を提供する- 合格
EstablishmentReportDNS解決とプロキシ接続のさまざまな段階のタイミングを確認する可能性 - ネットワークの動作を細かく制御する必要があるシナリオに適しています
サーバー側の適応
サーバーが位置の決定に IP アドレスに依存している場合は、調整を行う必要があります。
Private Relay のプロキシ IP アドレスは、都市または地域ごとにマッピングされます。 Apple はこれらのプロキシ IP アドレスのリストを公開しているので、正しい GeoIP データベースを使用してそれらを一般的なエリアにマッピングできます。
しかし、中心的なアドバイスは次のとおりです。位置と ID を推測するために IP アドレスを使用するのはやめてください。
// 推荐:显式请求用户位置
import CoreLocation
let locationManager = CLLocationManager()
locationManager.requestWhenInUseAuthorization()
// 获取位置后按需使用
locationManager.startUpdatingLocation()
キーポイント:
CoreLocation明示的なユーザー認証に基づいており、IP 推論よりも正確です- 過剰な取得を避けるために必要な精度レベルを指定できます
- IP アドレスの地理位置情報は、特にモバイル ネットワーク上では本質的に不正確です
ネットワーク管理者向けの注意事項
プライベート リレーを有効にすると、ネットワーク トラフィックに 2 つの明らかな変化が生じます。
-
UDP ポート 443 トラフィックの増加 — これは、プライベート リレー プロキシとの通信に使用される QUIC/HTTP/3 プロトコルです。ファイアウォールが UDP 443 を許可していることを確認してください。
-
クリア テキスト DNS クエリが削減されます — DNS クエリは暗号化されてプロキシ サーバーに送信されるためです。
企業または学校のネットワークで、すべてのトラフィックを監査する必要がある場合は、プライベート リレー プロキシ サーバーのホスト名をブロックできます。デバイスが接続すると、現在のネットワークでプライベート リレーを無効にするか、別のネットワークに切り替えるかをユーザーに求めるプロンプトが表示されます。
(13:43)
コンテンツ フィルタリングとペアレンタル コントロール
アプリがコンテンツ フィルタリングまたはペアレンタル コントロールを提供している場合、幸いなことに、フィルタはプライベート リレーに入る前のトラフィックを引き続き確認できます。
NetworkExtension フレームワークのコンテンツ フィルタリング API を使用します。
import NetworkExtension
// 注册内容过滤提供程序
let provider = NEFilterProvider()
// 过滤逻辑在设备本地执行,不受 Private Relay 影响
キーポイント:
- コンテンツ フィルタリングは、プライベート リレー処理の前にデバイス上でローカルに実行されます。
- 使用
NEFilterProviderそしてNEFilterDataProviderフィルタリングロジックを実装する - 具体的な実装については、「Meet the Screen Time API」セッションを参照してください。
重要ポイント
1.アプリ内の HTTP 接続の包括的な監査
- やるべきこと: プロジェクト内のすべての用途を確認してください
http://URL、すべてにアップグレードされましたhttps:// - 価値がある理由: プライベート リレーは安全でない HTTP トラフィックをプロキシしますが、これは中間的な保護にすぎません。エンドツーエンド暗号化は完全なソリューションです
- 開始方法: でアイテムを検索します
http://文字列。Info.plist を確認してください。NSAppTransportSecurity例外設定、1 つずつ削除
2. IP ロケーションの代わりにコアロケーションを使用
- 対処方法: サーバーが IP に基づいてユーザーの位置を推測する場合は、次を使用します。
CLLocationManager得る - 実行する価値がある理由: IP 測位は不正確であり、プライバシーを侵害します。コアの位置はユーザーの承認に基づいており、精度は制御可能です
- 開始方法: 位置情報が必要なページに位置許可リクエストを追加し、サーバーに推測させるのではなく、座標をサーバーに渡します。
3.ネットワーク デバッグ用にプライベート リレー検出を追加
- 何をすべきか: メトリクス収集をアプリのネットワーク層に追加して、どのリクエストがプロキシを通過するかをマークします。
- 実行する価値がある理由: ユーザーから報告されたネットワーク問題のトラブルシューティングを支援し、問題の原因がプライベート リレーによるものなのか、その他の理由によるものなのかを区別します。
- 開始方法: 既存の URLSession コールバックに追加します
task.metricsチェックする、記録するisProxyConnectionログに記録するステータス
4.サーバー側の不正行為対策ロジックを更新します
- 対処方法: サーバーがリスク管理またはスワイプ防止のために IP アドレスを使用する場合は、補足としてデバイス側の検証を追加します。
- 実行する価値がある理由: 複数のユーザーがプライベート リレーで同じプロキシ IP を共有するため、IP ベースの周波数制限により通常のユーザーが誤って被害を受ける可能性があります。
- 開始方法: 純粋な IP 次元の判断に代わる、デバイスレベルの検証のための DeviceCheck または App Attest を導入します。
5.エンタープライズ ネットワーク適応ガイド
- やるべきこと: 企業顧客向けにプライベート リレー互換性ドキュメントを準備する
- 実行する価値がある理由: 企業ネットワークには通常、厳格なトラフィック監査要件があります。サポートチケットを削減するために、設定方法を事前に通知してください。
- 開始方法: UDP 443 を有効にする必要性とプロキシ ホスト名ブロック ポリシーの構成方法についてヘルプ ドキュメントで説明します。
関連セッション
- 注目する Apple のプライバシーの柱 — Apple のプライバシー テクノロジーの基礎となる原則と設計哲学をより深く理解する
- Screen Time API の紹介 — プライベート リレーと共存するコンテンツ フィルタリングおよびペアレンタル コントロール API
- Instruments で HTTP トラフィックを分析する — Instruments を使用してプライベート リレーを通過するネットワーク トラフィックを分析する方法を学習します。
- 最新の Mac のネットワーク拡張機能 — VPN およびプロキシのシナリオを含む、最新の Mac ネットワーク拡張機能の開発
コメント
GitHub Issues · utterances