HTTPS トラフィック検出における Wehe の欠点を理解する

リンク一覧

概要と序論

関連研究と背景

TD検出測定装置開発における課題

ケーススタディ: Wehe - モバイル環境向け TD 検出ツール

HTTPS トラフィックにおける Wehe の欠点

HTTPSトラフィックのTD検出

結論と参考文献

V. HTTPSトラフィックにおけるWEHEの欠点

私たちの研究は、再生されたトラフィックストリームに対するネットワーク応答、TD検出、およびさまざまなネットワーク構成での運用可能性の検証に焦点を当てています。運用可能性はGoogle Playstoreで公開されている「Wehe」Androidアプリを使用して検証され、TD検出シナリオは理論的な議論を使用して検証されます。ネットワーク応答の検証には、受信したトラフィックストリームの帯域幅分析が必要です。この分析には、検証シナリオに従って実行された特定の再生のネットワークログが必要です。デバイスで行われた再生と、他の複数のストリーミング

図6. YouTube再生トラフィックのトラフィック分類

複数のサービスを並行して実行することは、そのようなシナリオの 1 つです。Wehe アプリは、テストの完了後にリプレイのネットワーク ログをすぐには提供しません。そのため、Wehe ツールの動作を模倣するユーザー クライアントとサーバーを実装しました。

Wehe の検証には、図 3 に示すセットアップと同様のクライアント サーバー セットアップを使用します。現在のセットアップでは、元のサービスのサーバーをリプレイ サーバーに置き換えました。ユーザー クライアントとリプレイ サーバーは、商用トラフィック シェーパーを介して接続されます。さらに、セットアップには複数のリプレイを並行して実行する機能があります。検証セットアップでは、サイド チャネルなどの管理チャネルやオーバーヘッドは必要ありません。サーバーは常に単一ユーザー クライアントをサポートする必要があります。複数のクライアントを使用するシナリオの検証では、関連するトラフィック分析が不要なため、Wehe アプリを直接使用します。

このセクションのリマインダーでは検証の結果について説明します。

A. オリジナルサービスのトラフィックエミュレーション

ネットワークの応答は、セクション III-A で説明したように、ネットワーク ミドルボックスによる正しいプローブ トラフィック分類に基づくネットワーク ポリシーの適用に依存します。Wehe のエミュレートされたトラフィックの分類は、市販のトラフィック シェーパーを使用して検証しました。エミュレートされたトラフィックの分類は、市販のトラフィック シェーパーのユーザー インターフェイスを使用して確認されます。

実験を行うために、YouTube アプリケーション データは、商用トラフィック シェーパーを介して再生サーバーからユーザー クライアントに再生されます。データ転送中、商用トラフィック シェーパーのユーザー インターフェイス ウィンドウで YouTube トラフィックの存在が観察されます。また、インターネット ブラウザーを使用して YouTube トラフィックにアクセスし、トラフィック シェーパーの分類結果を観察し、トラフィック分類の観察のベースラインを設定しました。

図 6 は、YouTube サーバーからインターネット ブラウザーを使用して直接アクセスしたトラフィックについて、商用トラフィック シェーパーのユーザー インターフェイス ウィンドウに表示されるトラフィック分類結果を示しています。左側のウィンドウにはインターネット アクティビティが表示され、右側のウィンドウには対応するトラフィックの分類が表示されます。

図 6(a) は、インターネット ブラウザを使用してアクセスされたトラフィックが YouTube として正しく分類されていることを示しています。これは、商用トラフィック シェーパーの意図された動作と一致しています。

図 6(b) は、ユーザー クライアントを使用してアクセスされたトラフィックのトラフィック分類結果を示しています。通信リンクを介して YouTube トラフィックが転送されていない証拠を示しています。さらに、同じトラフィックを HTTPS トラフィックとして分類しています。この実験の結果は、すべてのネットワーク ミドルボックスが Wehe の再生トラフィックを正しく分類できるわけではないことを示しています。

B. リプレイスクリプトにおけるデータレートの影響

プロービングトラフィックの生成は、TD検出アルゴリズムによって予測されるように、ネットワーク応答に影響を与えます。元のサービスからのトラフィックトレースを使用して、アプリケーションデータとそのタイミング関係を保持するリプレイスクリプトを生成します。このリプレイスクリプトは、元のネットワークだけでなく、地理的に異なる場所にあるネットワークでも使用されます。トラフィックシェーピングレートは同じサービスでもネットワーク間で異なるため（[32]で述べたように）、リプレイスクリプトで保持されるトラフィックレートは、現在検討中のネットワークのトラフィックシェーピングレートと異なる場合があります。リプレイトラフィックレートは、トラフィックシェーピングレートよりも低くなる可能性があります。

Wehe 方式では、再生スクリプトのトラフィック レートがネットワークのシェーピング レートよりも低い場合、トラフィック ストリームに影響を与えないため、トラフィックの差別化を検出しません。このような再生スクリプトでは、このようなネットワーク上のトラフィック シェーピングを検出できません。したがって、Wehe ツールの TD 検出機能は、再生スクリプトのプローブ トラフィック レートによって制限されます。

C. ポート番号80の使用

ネットワーク応答は、プローブ トラフィックに関するネットワーク ミドルボックスの認識によって駆動されます (セクション III-A を参照)。再生スクリプトは、アプリケーションの元のネットワーク トレースのデータを保持します。元のアプリケーション サーバーは、プレーン テキスト データにポート 80 を使用し、暗号化されたデータ転送にポート 443 を使用します。Wehe 再生スクリプトは、アプリケーションのネットワーク トレースからの暗号化されたデータを直接使用し、ポート 80 で送信します。このような場合、Wehe は、元の再生トラフィック ストリームが、暗号化されたアプリケーション データを使用するネットワーク デバイスによって正しく分類されることを期待します。暗号化されたトラフィック データはネットワーク デバイスにその ID を公開できないため、ポート 80 上のこのようなデータは不可能です。したがって、再生実行にデフォルトでポート 80 が使用されるため、Wehe ツールはポート番号 443 で実行されているサービスに必要なトラフィック ストリームを生成できません。

D. トラフィック負荷によって制御されるネットワーク動作

リソース不足により、ネットワークは、特にネットワーク負荷が高いシナリオでは、ネットワーク上のすべてのアクティブなサービスに有益な、QoSベースのトラフィック管理などの特定のネットワークトラフィック管理を適用するよう促されることに注意してください（セクションIII-Aを参照）。このようなトラフィック管理の効果を検証しました。

図7. ネットワーク負荷がWeheのトラフィックストリームパフォーマンスに与える影響

コントロールとオリジナルのリプレイのパフォーマンスについて検証します。検証には次の3つのシナリオを使用します。

• ネットワークに負荷をかけずにWeheの2つのトラフィックストリームのみを再生する（図7(a)）

• Weheの3つのトラフィックストリームを、1つの追加ストリーミングサービスを並行して実行しながら再生する（図7（b））

• 2つの追加ストリーミングサービスを並行して実行しながら、Weheの3つのトラフィックストリームを再生する（図7(c)）

図 7(a) のパフォーマンスは、Wehe ツールによって生成されたトラフィック ストリームのパフォーマンスが、追加のネットワーク負荷条件下では同じであることを示しています。ネットワーク負荷が増加すると、制御リプレイのパフォーマンスは元のリプレイのパフォーマンスから逸脱し、より高いレベルになります (図 7(b))。制御リプレイのパフォーマンスは元のリプレイからさらに低いレベルに逸脱しますが、図 7(c) に示すように、2 つの元のリプレイは依然として同様のパフォーマンスを示しています。これは、制御リプレイが差別化されないという Wehe ツールの期待を無効にします。また、総帯域幅による TD を検出するというツールの主張も無効にします。

E. 同じサブネット内の複数のデバイスからテストを実行する

サイドチャネルは、複数のユーザークライアントを同時にサポートするために Wehe の設計に導入されています。サイドチャネルは、ユーザークライアントと IP アドレスおよびポートの組み合わせ間のマッピングを識別するのにも役立ちます。これは、NAT [33] を使用するネットワークの場合に便利です。Wehe の複数クライアントおよび NAT 対応ネットワークのサポートを、2 つの異なるテストを使用して検証しました。最初に、同じサブネット内から 2 つのユーザークライアント (つまり、同じパブリック IP アドレスを共有するクライアント) を接続しました。1 つのテストでは、Wehe ツールは両方のデバイスで同じサービスをテストします (例: 両方のデバイスの Wehe アプリで YouTube をテストします)。結果には、Wehe テストが 1 つのデバイスでのみ完了したのに対し、別のデバイスでは Wehe アプリが突然終了したことが示されています。同じシナリオを繰り返しましたが、今回は Wehe が別のサービスをテストします (例: 1 つのデバイスで Wehe が YouTube をテストしているときに、別のデバイスで Netflix をテストします)。あるデバイスでの Wehe テストは正常に完了しますが、別のデバイスでの Wehe テストでは、図 9 に示すように、別のクライアントがすでにテストを実行していることをユーザーに通知するエラーが画面に表示されることがわかりました。これらのテストは、同じ IP アドレスを共有する複数のデバイスを Wehe がサポートしていないことを示しています。サイドチャネルは、Wehe リプレイ サーバーに直接接続されたユーザー クライアントからの各リプレイを識別するのに役立ちますが、NAT デバイスを使用するネットワークでは役に立ちません。NAT の場合、複数のユーザーが同じ IP アドレスを共有します。このような場合、サイドチャネルは各リプレイ実行をクライアントに一意にマッピングできません。これにより、Wehe の使用は、リプレイ サーバーと ISP およびアプリケーションごとに 1 つのアクティブ クライアントのみに制限されます。この制限は、Wehe 開発者によっても文書化されています。

F. デバイスのネットワーク負荷がTD検出に与える影響

Wehe のリプレイ サーバーは、アプリケーション データ転送間のタイミングを、元のアプリケーション トラフィックのタイミングと同じにします。このような転送戦略では、使用可能な帯域幅を使い果たさないことが期待されます。したがって、使用可能な帯域幅を超えるトラフィック レートのオーバーシュートによるソース レート変調の影響は発生しにくいです。これにより、ネットワーク ポリシー (TD など) によって意図的に変更されない限り、元のリプレイとコントロール リプレイは同様のトラフィック パフォーマンスを示します。

ただし、Wehe テストの実行中にユーザー デバイスのネットワーク負荷によってトラフィック データ レートが調整されるため、この期待は常に満たされるわけではありません。このような変動により矛盾が生じます。プローブ トラフィックに対する時間変動する現在のネットワーク負荷の影響も時間変動し、常に同じとは限らないためです。Wehe のバックツーバック リプレイ戦略により、両方の (元のリプレイとコントロール リプレイ) プローブ トラフィック ストリームが、現在のネットワーク負荷によって異なる影響を受けるようになります。デバイス側のこのようなネットワーク負荷では、利用可能な帯域幅を使い果たさないサービスという概念は、TD 検出の利点とともに存在しなくなります。TD 検出の前に、このような交絡因子を正規化する必要があります (セクション III-B を参照)。