はじめに（この記事で分かること）#

「Torは破られた」「暗号は役に立たない」という見出しが出るたびに、実際には何が起きたのかを確認する必要がある。netguardiaの分析によれば、Tor利用者の特定事例のほとんどは、Torプロトコル自体の欠陥ではなく、利用者の環境や使い方の問題である。

この記事では、Tor Browserの実践的な使い方を、身バレの典型パターンと対策とともに整理する。

前提: 脅威モデルの整理#

Torが有効な相手は、脅威モデル入門で整理した5種類の相手のうち、主に2者だ。

ISPは、Torを使っているという事実は知るが、通信先と通信内容は知らない。プラットフォームは、Tor経由のアクセスを拒否したり、CAPTCHAで制限したりするが、Tor出口ノードのIP以外の情報は得られない。

法執行機関は、NIT（Network Investigative Technique）と呼ばれる技術で、Torの外に実IPを送り出すことがある。ただし、netguardiaの分析によれば、これは「Torの欠陥」ではなく、占有したonionサービスにブラウザ悪用コードを仕込む手法である。

3ホップの仕組み#

Torは、通信を3つの中継点（ガード、ミドル、出口）を経由させる。どの中継点も「誰が」と「どこへ」の両方を同時には知らない。

ガードリレーは、送信者のIPアドレスを知るが、通信先は知らない。出口リレーは、通信先を知るが、送信者のIPアドレスは知らない。ミドルリレーは、両方を知らない。

この設計により、単一の中継点が侵害されても、送信者と通信先の両方を同時に特定することはできない。

セキュリティレベルの使い分け#

Tor Browserは、3つのセキュリティレベルを提供している。

Standardレベルでは、JavaScriptが有効になっている。すべてのサイトが動作するが、フィンガープリントやNITのリスクが高くなる。

Saferレベルでは、HTTPS以外のページでJavaScriptが無効になる。一部のサイトが動作しなくなる。

Safestレベルでは、すべてのページでJavaScriptが無効になる。多くのサイトが動作しなくなるが、攻撃面が最小になる。

セキュリティレベルを上げる意味は、ブラウザの脆弱性を突くコードが動く余地を減らすことにある。Playpen事件では、FBIのNIT（捜査用コード）がTor Browserに組み込まれたFirefoxの脆弱性を突いたとみられ、訪問者の実IPがTorの外へ送られた（EFF）。ただし、このNITがJavaScriptを前提にしていたかどうかは、公開された資料では確認できない。2016年に悪用されたFirefoxの脆弱性（CVE-2016-9079）については、Tor Projectが「セキュリティスライダーを『High』にしていた利用者は安全だったとみられる」と説明している。セキュリティレベルは、すべての攻撃を止めるものではないが、突かれる面を狭める。

身バレの典型パターン#

Tor Browserを使っていても、以下の行為が身バレの原因になる。

実名のアカウントへのログイン#

Tor Browserで実名のGoogleアカウントにログインすれば、Googleはそのセッションを本人のものとして記録する。Torが隠したIPアドレスとは関係なく、アカウントの紐付けが発生する。

ファイルのダウンロードと開封#

Tor Browserでダウンロードしたファイルにマルウェアが含まれていた場合、開封時に端末自体が侵害される。Torの匿名性は、ダウンロードしたファイルの安全性を保証しない。

メタデータの露出#

Tor Browserでアップロードした画像にEXIFのGPS座標が残っていれば、撮影場所と時刻が露出する。Torは画像ファイルの中身を検査しない。

クッキーの残留#

Tor Browserはセッション終了時にクッキーを消去するが、セッション中に同じサイトを複数回訪問すると、クッキーによる紐付けが発生する。Circuit Isolation機能により、異なるドメインへのアクセスは別の回路を使うが、同じドメインへの複数回のアクセスは同じ回路を使う。

Torを使っていること自体の露出#

IPアドレスから個人を特定される仕組みで説明したとおり、Torの利用が少ない環境では、「Torを使っている」という事実自体が指紋になる。Harvard大学の爆破予告事件では、学内ネットワークからTorに接続した記録が、候補者の絞り込みに使われた。

ブリッジの使い分け#

検閲環境では、Torへの直接接続が遮断されることがある。ブリッジは、Torへの接続を検閲者から見えにくくする仕組みである。

obfs4は、Torの通信パターンを無相関のランダムデータに変換する。WebTunnelは、HTTPSトラフィックに変装する。Snowflakeは、WebRTCを利用したP2P接続を利用する。meekは、CDN（Cloudfront、Azure）のドメインフロンティングを使う。

Pluggable Transportの記事で、各PTの仕組みと使い分けを詳しく説明する。

Tor Browserの更新#

Tor Browserの更新は、セキュリティのために必須である。古いバージョンのTor Browserは、修正済みの既知の脆弱性をそのまま抱えている。2016年のCVE-2016-9079のように、実際に悪用が見つかった脆弱性もある。一方、PlaypenのNITは未知の脆弱性を使った可能性があり（Mozillaが裁判所に提出した申立書）、その場合は更新していても防げなかった。更新は必須だが、更新だけで十分とは言えない。

2024年にドイツで報じられたTor利用者の特定事例について、Tor Projectは9月18日の声明で、開発が終わった古いアプリケーションRicochetの利用者1人がguard discovery攻撃で特定されたとみられ、その版にはVanguards-liteもvanguardsアドオンも入っていなかったと説明した。ただし10月10日の追記では、対象のサービスでVanguardの保護が有効だったかは確認できず、正確な手法は分からないとしている。古いソフトウェアが入口になった可能性は高いが、確定はしていない。詳しくは通信のタイミング相関で扱う。

限界と残るリスク#

Torの匿名性は、3ホップの設計と、各リレーが独立して運営されていることに依存している。入口側と出口側の両方を観測できる相手は、タイミング相関で通信を紐付けうる。同じ攻撃者がガードと出口のリレーを運営している場合のほか、利用者側と通信先側の両方の回線を見られるISPや国家機関もこれにあたる。Torの設計論文は、この種の攻撃を完全には防がないと明記している。Torが入口のガードを少数に固定するのは、悪意あるガードに当たる機会を減らすためで、相関そのものを防ぐ仕組みではない。

Tor Browserのセキュリティレベルを上げると、多くのサイトが動作しなくなる。使いやすさと匿名性のトレードオフは、脅威モデルによって判断する。

Tor Browserを使っていても、アカウントのログイン、ファイルのダウンロード、メタデータの露出、行動パターンの蓄積は、匿名性を崩す。Torは通信経路の匿名化であり、利用者の行動パターンの匿名化ではない。

まとめ#

Tor Browserは、設計どおりに動いている。身バレの大半は、使い方とエンドポイントにある。

ブラウザの脆弱性は実IPが漏れる入口になりうるし、実名アカウントへのログインは紐付けの起点になり、メタデータの露出は位置情報を明かす。後の二つは習慣で防げる。一つ目は、更新とセキュリティレベルで突かれる余地を減らせるが、未知の脆弱性まで含めて防ぎきれるものではない。

検閲環境では、ブリッジが必要になる。obfs4、WebTunnel、Snowflakeの使い分けは、Pluggable Transportの記事で詳しく説明する。

VPNとTorの組み合わせについては、VPN over Tor / Tor over VPNで、順序の違いが意味を変えることを説明する。

出典#