WebRTCリーク:プロキシ経由でも本当のアドレスが見えてしまう理由

WebRTCは、ブラウザ同士が通話や画面共有のために直接やり取りできるようにするための仕組みです。そのために、ブラウザは自分に到達できるアドレスを探し出す必要があり、この探索の過程が「WebRTCリーク」の指すものです。
ICE候補を一段落で
ページがRTCPeerConnectionを作成してオファーを開始すると、ブラウザは候補、つまり他のピアが自分に到達できる経路を集めます。host候補はローカルインターフェースのアドレスです。server-reflexive(srflx)候補は、STUNサーバーがリクエストの到着元として確認した公開アドレスです。relay候補はTURNサーバーのアドレスです。各候補はアドレスを含むテキスト行としてページに渡されるため、通話が一度も行われなくても、スクリプトはそれを読み取れます。
リークはどこにあるか
重要なのはsrflx候補です。これを得るために、ブラウザはSTUNサーバーへ小さなUDPパケットを送り、サーバーは見えたアドレスを返信します。HTTPトラフィックはプロキシを通っていてもUDPトラフィックは通っていない場合、STUNサーバーには本当の接続元が見え、ページはウェブサーバーが見たアドレスと食い違うアドレスを手にします。この食い違いが典型的なリークです。診断ページは、二つを比較することでそれを示せます。
何が起きていて、何が起きていないかに注意してください。メディアは取得されません。マイクやカメラの許可も関係しません。パケットはページが指定したSTUNサーバーに送られるため、そのサーバーは、あなたが接続する他のサーバーと同様に、あなたのアドレスを目にします。
ブラウザが変えたこと
かつてhost候補は192.168.1.23のようなプライベートLANアドレスを露出し、家庭内ネットワークのフィンガープリントに利用されました。現在のブラウザは、これを.localで終わるランダム生成のmDNS名に置き換えるため、ページにはアドレスではなく意味の読み取れない名前が見えます。診断が「ブラウザによりマスク済み」と報告するのは、これらのことです。FirefoxとBraveには、プロキシの外での候補収集を止める設定もあり、WebRTCを完全にブロックする拡張機能もあります。
プロキシで安全な設定
コストの異なる三つの方法があります。WebRTCを無効にすればリークは防げますが、それを必要とするすべてのサイトが動かなくなります。WebRTCにプロキシの経路だけを使わせる(一部のブラウザの「プロキシセーフ」モード)と、プロキシがUDPまたはTURNに対応していれば通話は動作し、そうでなければ公開候補がまったく得られません。WebRTCを通常どおり動作させるのは、システムレベルのVPNのように、プロキシがすべてのトラフィックを運ぶ場合にのみ正しい選択です。
どれが適切かは作業内容によります。一か所にいるように見えなければならない分離されたブラウザプロファイルの場合、ルールは単純です。WebRTCが露出するアドレスは、ウェブサーバーが見るアドレスと同じか、何もないかのどちらかでなければなりません。それ以外は、特別なツールがなくてもサイトに気づかれる矛盾です。
結果の読み方
診断は数秒のうちに観測した候補を表示し、公開候補があれば、ページに到達した際のアドレスと比較します。WebRTCをプロキシの中に収めているブラウザでは、マスクされた候補がいくつかあって「露出なし」と出るのが、通常で健全な結果です。ページのアドレスと異なる公開アドレスが見つかった場合は、直すべき対象です。


