WebRTCによるIPリーク検知：バグから機能へ

WebRTC（Web Real-Time Communication）は、ビデオ通話、ファイル共有、ピアツーピアのデータ転送をブラウザ内で直接可能にするために設計されました。これらの接続を確立するために、ブラウザは自身のネットワークインターフェースを発見し、リモートのピアとの接続性をネゴシエートする必要があります。このプロセスにはSTUN（Session Traversal Utilities for NAT）およびTURN（Traversal Using Relays around NAT）サーバーが関わり、ブラウザが自身の公開IPアドレスを発見してNATファイアウォールを越える手助けをします。

その副作用は強力です。ユーザーがVPN経由で接続している場合でも、ブラウザのWebRTCスタックがトンネルの背後にある実IPアドレスを露呈することがあります。これは、WebRTC ICE（Interactive Connectivity Establishment）候補に、VPNが隠さないローカルネットワークインターフェースのアドレスが含まれるために起こります。

リークの仕組み

ブラウザがRTCPeerConnectionを作成してICE候補を収集すると、STUNサーバーに問い合わせて公開向けのIPを発見します。しかし同時に、物理アダプタのプライベートIPを含むローカルネットワークインターフェースも列挙します。VPNがIP層でトラフィックをトンネリングするだけで、ブラウザのWebRTCスタックがトンネルインターフェースを排他的に使用するように構成していない場合、実IPがホスト候補を通じてリークします。

tracio.aiでは、この挙動を慎重にプローブします。当社のIP Intelligenceシステムは制御されたSTUNリクエストを作成し、ブラウザが返すICE候補を分析します。STUNからの公開IPが当社のサーバーで観測されるIPと異なる場合、VPNまたはプロキシとしてフラグを立てます。ローカルインターフェースのIPが、想定される地理的位置と矛盾するプライベートネットワーク範囲を明らかにする場合、疑いスコアを引き上げます。

バグから検知シグナルへ

プライバシー重視のブラウザのほとんどは、このリークにパッチを当てています。ChromeはWebRTCに明示的なユーザー許可を要求し、Firefoxは非プロキシUDPを無効化する設定を提供しています。しかし軍拡競争は続いています。一部のVPNクライアントはWebRTCを適切に構成しておらず、古いブラウザバージョンは依然として脆弱であり、そして「パッチ済み」と「リークする」WebRTC応答の挙動パターンそのものが有用なシグナルなのです。

当社のアプローチは、WebRTC応答を複合シグナルとして扱います。ホスト候補の有無、返されるICE候補の数、候補の種類（host、srflx、relay）、そして応答タイミングのすべてがデバイスフィンガープリントに寄与します。IPが一切リークしない場合でも、WebRTCの挙動パターンは特徴的です。

TURNサーバーのプロービング

STUNに加えて、当社はTURNサーバーの挙動もプローブします。TURNリレーは通常、直接のピアツーピア接続が失敗したときに使用されます。厳格なファイアウォールの背後にある企業ネットワークでよく見られます。TURN割り当て応答は、リレー経路に関する情報を明らかにします。トランスポートプロトコル（UDP対TCP対TLS）、リレーアドレス、割り当ての有効期間です。

当社のSignalProbeシステムは、当社自身のリレーサーバーに巧妙に作られたTURN割り当てリクエストを送信します。応答時間、サポートされるトランスポート、割り当ての成功/失敗のパターンはネットワーク環境によって異なり、デバイスフィンガープリンティングに追加のシグナルの多様性を提供します。

プライバシーへの配慮

明確にしておきたいことがあります。tracio.aiは、ユーザーを匿名解除するためにWebRTCリークを悪用することはありません。当社のシステムはVPNが使用されているときにそれを検知し、これをリスクシグナルとして報告します。リークしたIPアドレスを保存したり露出したりすることは決してありません。シグナルはバイナリです。「WebRTC不整合を伴うVPN検知」または「直接接続と整合するWebRTC挙動」のいずれかです。

このアプローチは、不正防止チームが必要とする情報、すなわち訪問者が実際の位置を隠しているという情報を、個人のプライバシーを損なうことなく提供します。このシグナルは、複数のアカウントが同じ隠された位置から発生する協調的な不正攻撃の検知に役立ちます。