タイミング攻撃は、Torネットワークの有名な弱点であり、Habréを含め、繰り返し議論されています。Habréでは、このトピックに関する約10の記事があります。 なぜ別のものが必要なのですか？ そのような攻撃は常に統計分析を必要とし、実装が非常に難しいというかなり一般的な誤解があります。 以前に公開された記事は、このクラスの攻撃に特に関連しています。 単一の要求でネットワークユーザーの匿名化を行うのに十分な非常に現実的なシナリオを検討します。
Torユーザーの匿名化の可能性の問題はRuNetで再び活発に議論されているため、PHDays 2014でプレゼンテーションの断片の「印刷」バージョンを公開しています。以下の攻撃はTorに限定されず、トラフィックソースを隠す低遅延手段（VPN、チェーン）に対して使用できますプロキシ、さらにはそれらの組み合わせ。
Torでの実装が次の2つの条件を必要とするシナリオを検討します。
- 出口ノードと宛先ノード間のトラフィックを妨害できるようにします。 これは、宛先サーバー、出口ノード、またはそれらの間でトラフィックが流れる任意のポイントにアクセスすることで実行できます。 つまり、実際には、十分な量の独自の出口ノードを編成することで、誰でもこの条件を満たすことができます。
- ネットワーククライアントとエントリノード間のトラフィックに受動的にアクセスします。
そして、特別なサービスはどうですか？ ロシアのプロバイダーにインストールされたSORM機器は、通常完全に受動的であり、指定された特性を持つトラフィックを検出、記録、解釈（たとえば、インスタントメッセンジャーの通信の復元）できます。 「外部から」この機器の存在を追跡することは、独自のトラフィックを生成せず、リスナーに影響を与えないため、実際には不可能です。
SORM機器への攻撃者のアクセスは、2番目の攻撃条件を完全に満たします。 つまり、機器にアクセスでき、Torで一定数の出口ノードを編成できる特別なサービスには、この問題に対処したいという欲求など、必要なすべてのものがあります。
攻撃原理
出口ノード側から、送信データを変更しないが、トラフィックの「フォーム」に影響するトラフィックに事前定義された変更が行われます。通過するパケットのサイズとパケット間の遅延が変更されます。 低遅延ネットワークのタイミング特性は大きく変化しません。この事実は通常、タイミング攻撃で使用されます。 実証されるように、パケットサイズは予測可能な方法で変化します。 これは、特定の遅延シーケンスを使用してトラフィックを特定のサイズのパケットに再分割することにより、出口ノード側でトラフィックをマークできるため、エントリノード側でこのマーキングを検出できるため、Torユーザーとのサーバーへの接続または要求を関連付けることができますさらに、このトラフィックでは、リスニングパーティの情報、たとえばクライアント要求の一意の識別子を送信することができます。 つまり、パケットサイズに2つの区別可能なオプションと時間遅延に2つの区別可能なオプションがある場合、ユーザーとエントリノード間の暗号化されたトラフィックをリッスンしている各当事者に2ビット目から2ビットの情報をユーザーから密かに渡すことができます。 実際、より識別可能な状態を導入できますが、以下で説明する追加の制限があります。
これはどれほど困難であり、実際にどのように見えますか？
出口ノードのトラフィックをプロキシサーバーにリダイレクトすることで攻撃を実装しました。プロキシサーバーには、事前に定義されたテンプレートに従ってトラフィックシェーピングを整理するための小さな変更が加えられました。Torの「通常の」トラフィックはどのように見えますか？ これは、トラフィックにマーキングを入力せずに、HTTP要求の結果の送信に関連付けられたエントリノードからクライアントへのトラフィックのフラグメントです。
TLSトラフィックがあり、その中には主にサイズが3648オクテットの情報の塊（パケット）があります。 BLOBサイズは、固定サイズのtorトラフィックセルの数によって決まります。 TCPレベルでは、ブロブは主にサイズが1414オクテットのIPパケットに分割され、これはパスMTUに関連付けられています。 TCPパケットには、1つのblobのフラグメントと、1つのblobの終わりと次のblobの始まりの両方を含めることができます。 ただし、560オクテットのblobとより小さいTCPパケットがあります。 ソースデータのBLOBへの分割とBLOBのTCPパケットへの分割は、さまざまなパラメーター（サーバーのタイミング、データを送信するバッファーのサイズ、およびネットワーク遅延）に依存します。 再クエリを行うと、画像が若干異なる場合があります。 ただし、統計的には、同じサーバーへの同じリクエストの状況はかなり明確です。 同じWebページを読み込むと、データを照合することにより、原則として同じリクエストとレスポンス、つまり典型的な遅延を伴う典型的な情報量の送信により、かなり多数のリクエストが発生するため、ユーザーがアクセスしているリソースを見つけることができます特に彼が定期的に彼を訪れる場合。 従来のタイミング攻撃はこれに基づいています。
しかし、我々は反対の方向に進んでいます。 パッシブタイミング測定の代わりに、シェーピングマーキング（maRk）を出口ノード側からのソーストラフィックに追加します。 Torを通過する純粋な暗号化されていないトラフィックは、次のようになります。
ラベルはどのように機能しますか？ 2つの異なるサイズの小さなパケットを転送します。 この場合の数百バイトのサイズの違いは何にも影響しませんが、一連のパケットの2つの異なるタイプを視覚的に区別できます。 2種類のパケット間の遅延は60ミリ秒と110ミリ秒です。これらは、出力で最も興味深い画像が表示されるように選択されます。
同じトラフィックがTorを通過すると、エントリノードとユーザーの間は次のようになります。
私たちは今何を見ていますか。 TLSのすべてのblobのサイズは560オクテットになりました（つまり、トラフィックの大部分または小部分を送信することで3648または560オクテットのサイズを管理できます）。 ところで、この場所ではトラフィックの増幅の問題があります-最小データパケットは10倍以上増加します。 送信する各パッケージは、TLSの個別のBLOBとして提供されます。 同時に、1414オクテットIPパケットには2つの完全なブロブと、3番目の開始、389オクテットパケット— 3番目のブロブの終了、619オクテットパケット— 4番目の別のブロブが含まれます。 つまり、ソーストラフィックの4つのIPパケットは、Torトラフィックの3つのIPパケットになります。 それは良いですか悪いですか？ タイミング情報の一部を失ってしまったためです。
何が起こったのか、なぜそのような奇妙なシーケンス：TCPスタックの特性、つまりNagleアルゴリズムとTCP遅延確認応答の共同操作が原因です。 ただし、パッケージのグループ間およびグループ内のパッケージ間では、間隔は変更されません。つまり、受信するタイミングに関する情報の少なくとも半分です。 Nagleアルゴリズムで待機およびグループ化を「克服」するために、送信されたBLOBがMTUサイズを超えるようにトラフィック量を送信できます（ただし、3648バイトの「大きな」BLOBを形成するには不十分です）。
3番目の画像を最初の画像と比較すると、かなり明確で簡単に検出できる異常がトラフィックに導入され、追跡機器が検出されたときに「動作」することが明らかになります。 さらに、SORMの場合、この異常の検出可能性は証拠ベースとして十分です。
この攻撃は、ほとんどすべての暗号化された接続または暗号化されていない接続に、サーバーからクライアントへの方向、およびその逆の両方で適用できます。
制限は何ですか？
Naglアルゴリズムによるトラフィックの「非線形」動作により、タイミング情報の一部が失われる可能性がありますが、この損失は受信側で検出され、送信された情報の冗長性によって補償されます。 トラフィックを整形可能にするには、トラフィックが十分でなければなりません。 たとえば、実行中のbashと定期的に発行されるコマンドを使用したssh接続では、必要なmaRk署名を持つパケットを形成するのに十分なデータが送信されないため、この方法でマークするのは難しいようです。実際、データがまったく送信されなかった接続をマークすることもできます。 実際、クライアントアプリケーションがTCP接続のクローズを開始した後でも、Torを介してクライアント側に送信されたデータは引き続き配信されます。 これにより、クライアント側からの接続でFIN + ACKを受信した後、ランダムデータのマークされた部分をクライアント側に送信できます。 このデータはクライアントアプリケーションによって読み取られることはありませんが、クライアントに到達するため、明らかになります。 つまり、攻撃はクライアントから完全に秘密裏に実行される可能性があり、接続をマークできる情報の量は十分すぎるほどです。 同様の方法はほとんどのVPNに適用できますが、幸いなことに、プロキシや他のアプリケーションゲートウェイでは機能しません。
信頼できるソリューションはありますか？
1つのチェーンに関連するパケットを検出する必要があるため、クライアントがアクティブに動作している場合、攻撃を実行するのがより困難になる可能性があります。 また、Torネットワークでリレーの役割を担うこともできます。これにより、タグ付きトラフィックの検出が困難になります。 攻撃をさらに複雑にする方法はいくつかあります。Tor、VPN、およびプロキシチェーンの組み合わせにより、トラフィックの最終形態を推測することが難しくなり、ハーフクローズ接続による攻撃を部分的に排除します。 TCPスタックの非標準パラメーターで既知の署名を台無しにすることにより、検出を複雑にすることができます。 しかし、Torまたは広範囲のVPNネットワーク内でこのような脅威を完全に排除する信頼できる方法はありません。 タイミング攻撃の一形態としてのシェーピング攻撃は、防御プロファイルの範囲外です。唯一の信頼できる解決策は、暗号化された接続内で仮想リンクを使用することです。この仮想リンクでは、固定帯域幅で固定長のセルの一定ストリームが存在します。 これは、たとえば、ATMネットワーク（非同期転送モード）の仕組みです。 さらに、暗号化はデータ圧縮なしで実行する必要があります。つまり、消費帯域幅は変更しないでください。 このような技術は、ダウンタイム時にも積極的に使用されているチャネルの追加コストが高すぎるため、日常業務に広く使用することはまだできません。