OpenVPNのフィンガープリント可能性を暴露する新たな研究が発表され、プライバシーへの懸念が高まる

はじめに

VPNのフィンガープリンティングとは？

特定のVPNプロトコルを識別し、通常のインターネット通信と区別する技術です。これにより、政府機関、インターネットサービスプロバイダー（ISP）、または攻撃者がVPNトラフィックを検出し、場合によっては制限または監視することが可能になります。

VPNのフィンガープリンティングは、ユーザーのデバイスやブラウザの特性を利用して、特定のユーザーを識別する手法です。これは、VPNを使用している場合でも、ユーザーのプライバシーを脅かす可能性があります。

フィンガープリンティングは、以下のような情報を収集することで行われます。

・ブラウザ情報:
使用しているブラウザのバージョン、プラグイン、フォント、言語設定など。

・デバイス情報:
オペレーティングシステム、デバイスの解像度、タイムゾーンなど。

・ネットワーク情報:
IPアドレスや接続の種類（Wi-Fi、モバイルデータなど）。

これらの情報を組み合わせることで、特定のデバイスやユーザーを識別することが可能になります。

特に、VPNを使用している場合でも、これらの情報は変わらないため、フィンガープリンティングによる追跡が可能になります。 ・プライバシーへの影響
VPNは通常、ユーザーのIPアドレスを隠すことでプライバシーを保護しますが、フィンガープリンティング技術はこの保護を回避することができます。
・匿名性の低下
VPNを使用しても、フィンガープリンティングによってユーザーが特定される可能性があるため、完全な匿名性は保証されません。
・ターゲティング広告
フィンガープリンティングにより、ユーザーの行動が追跡され、ターゲティング広告が表示されることがあります。これにより、プライバシーが侵害される可能性があります。
・セキュリティリスク
フィンガープリンティング技術が悪用されると、個人情報の漏洩や不正アクセスのリスクが高まります。

このように、VPNのフィンガープリンティングは、ユーザーのプライバシーに対して新たな脅威をもたらす可能性があるため、注意が必要です。

今回のレポートでは、OpenVPNはバイトパターン、パケットサイズ、サーバー応答などのプロトコル機能に基づいて識別可能であることがわかったようで、 これらの情報をもとにフィンガープリントを作り出すことで、ISPや政府によって比較的容易に検知・ブロックされる可能性を示しています。

広く適用されている難読化技術を採用したOpenVPNでさえ、ネットワークベースの敵対者によって確実に検出およびブロックできることを実証されてしまっています。 この点を知った上で、レポートを読んでみてください。 どのように特定していったのか？

では、本編をじっくりと読んでみてください。

---

近年のプライバシーと監視の脅威に対する意識の高まりにより、VPNの利用は着実に増加しています。VPNは、公衆インターネット上で暗号化されたトンネルを作成することでプライベートネットワークを構築するツールです。IPSecやWireGuardなど、多くのVPNプロトコルが使用されていますが、OpenVPNは商用VPNプロバイダーの間で最もサポートされ、信頼されているプロトコルです。その汎用性とオープンソースであることから、OpenVPNは多くのVPN製品で基盤となるプロトコルとして使用されており、その実績のあるセキュリティを謳っています。さらに、ユーザーがオープンソースのVPNツールをセルフホストする傾向が高まっているため、OpenVPNの人気はさらに高まっています。

しかし、VPNの人気が高まるにつれて、ISPや政府機関は、自国の管轄区域内のトラフィックに対する可視性と制御を維持するために、VPNトラフィックの追跡やブロックを試みるようになっています。中国のグレートファイアウォール（GFW）の設計者である方浜興は、ファイアウォールとVPNの間には「永遠の戦争」があると述べており、中国はISPに個人VPNの使用を報告し、ブロックするように命じています。最近では、ロシアとインドがVPNサービスを国家のサイバーセキュリティの脅威とみなし、自国でのブロックを提案しています。商用ISPもVPN接続を追跡する動機を持っています。例えば、2021年初頭、南アフリカの大規模ISPであるRain, Ltd.は、データプランのサービス品質制限を強化するために、VPN接続を90％以上抑制し始めました。

ISPや検閲機関は、IPレピュテーションに基づく接続の追跡、VPNプロバイダー（以下、プロバイダー）のウェブサイトのブロック、VPNの使用を禁止する法律や利用規約の制定など、さまざまな単純なVPN対策技術を採用していることが知られています。しかし、これらの方法は堅牢ではありません。意欲のあるユーザーは、これらの方法にもかかわらずVPNサービスにアクセスする方法を見つけます。しかし、現在では、それほど強力ではないISPや検閲機関でさえ、キャリアグレードのディープパケットインスペクション（DPI）などの技術を利用できるようになっています。DPIは、プロトコルの意味に基づいてより高度な検出モードを実装することができます。

本レポートでは、**敵対的なISPの視点からOpenVPNのフィンガープリンタビリティを調査することにより、VPNの検出とブロックに対するDPIの影響を検証します。**具体的には、2つの研究課題に取り組みます。(1) ISPや政府機関は、トラフィックフローをリアルタイムでOpenVPN接続として識別できるか？(2) ISPや政府機関は、誤検知による大きな付随的損害を被ることなく、大規模に識別できるか？これらの課題に答えるには、フィンガープリンティングの脆弱性を特定するだけでは不十分です。困難ではあるものの、ISPや国家レベルの検閲機関が現実世界でどのように活動しているかの制約の下で、実際的な悪用を実証する必要があります。

本レポートでは、グレートファイアウォールの構造から着想を得た、フィルターとプローバーという2つのコンポーネントで構成される検出フレームワークを構築しました。フィルターは、通過するネットワークトラフィックに対してリアルタイムでパッシブフィルタリングを実行し、OpenVPNのハンドシェイク段階で特定されたプロトコルの癖を利用します。フィルターによってフローにフラグが立てられると、宛先アドレスはプローバーに渡され、プローバーは確認のためにアクティブプロービングを実行します。**プローバーは、プロトコル固有の動作を誘発するように注意深く設計されたプローブを送信することで、サーバーがアクティブプロービングに対するOpenVPNのオプションの防御を有効にしていても、サイドチャネルを使用してOpenVPNサーバーを識別することができます。**この2段階のフレームワークは、非常に低い誤検知率で、ISP規模のトラフィックをラインスピードで処理することができます。

コアまたは「バニラ」のOpenVPNに加えて、本レポートでは、商用の「難読化された」VPNサービスも検証対象に含めています。ISPや検閲機関からの干渉が増加していることを受けて、難読化されたVPNサービスは、特に検閲が厳しかったり、個人でのVPN使用が法律で禁止されていたりする国のユーザーの間で、注目を集め始めています。運営者が「不可視」や「ブロック不可能」と宣伝することが多い難読化されたVPNサービスは、通常、検出を回避するために追加の難読化層を備えたOpenVPNを使用します。

100万人のユーザーにサービスを提供する中規模の地域ISPであるMeritと提携し、Meritの主要なポイントオブプレゼンスからミラーリングされた20 Gbpsのイングレスおよびエグレストラフィックを観測する監視サーバーに、このフレームワークを展開しました（倫理的な配慮については、§5を参照してください）。高速なパケット処理のために、ゼロコピーモードでPF_RINGを使用し、並列化されたフィルターのZeekクラスター15台のワーカーにトラフィック負荷を分散させました。それでも、CPUリソースが限られているため、パケット損失の影響を最小限に抑えるために、ネットワークインターフェースに到着するすべてのTCPおよびUDPフローの12.5％のみをサンプリングしました。サンプリングはIPペアに基づいて行われるため、フローの双方向トラフィックはすべて一緒に選択/ドロップされます。これらの設定により、エンドツーエンドのパケット損失率を3％未満に抑えることができました。トラフィックの一部しか処理していませんが、**このフィルターは、1台のサーバーで、平均的な1日に15テラバイト以上のトラフィックを20億以上のフローから処理しています。**さらに、サンプリングを行わずにすべてのトラフィックを処理することは、並列化またはより高速なCPUを使用することで可能です。

次に、10個のIPv4アドレスと1個のIPv6アドレスをそれぞれプロビジョニングした、2台の専用の測定マシンにプローバーを設定しました。評価期間中、毎日終了時に、プローバーは監視ステーションからフィルタリングログを取得しました。ターゲットごとに、IPが属する/29サブネットに対して、すべてのTCPポート（1～65535）でMasscanを実行しました。検出された開いているポートごとにプロービングスキームを実行し、プロービングによって確認されたエンドポイントは手動分析のために記録されました。

評価対象のVPNサービスを選択するために、まず、人気順にランク付けされた「トップ」VPNサービスのリストを作成しました。以前の研究に基づき、トップVPN推奨サイトから、ほとんどが有料のプレミアムVPNサービスである80のプロバイダーを組み合わせました（付録の表4にリストされています）。次に、これらのVPNプロバイダーのウェブサイトを訪問し、「難読化」、「ステルス」、「カモフラージュモード」などを検索し、少なくとも1つの難読化されたVPN構成を提供しているプロバイダーを含めました。その結果、難読化されたサービスを提供しているプロバイダーは24社見つかりました。各プロバイダーについて、複数の難読化構成が提供されている場合はすべてテストし、バニラのOpenVPNもテストしました。TCPモードとUDPモードの両方が利用可能な場合は、別々にテストしました。合計で81の構成があり、そのうち41は難読化されたものです。

Merit内のクライアントステーションをVPNクライアントとして動作するように設定しました。クライアントステーションの上り下り両方のトラフィックは、監視ステーションにトラフィックをミラーリングするルーターを経由します。また、このサーバーはランダムサンプリングから除外し、このサーバーとの間のすべてのトラフィックが分析されるようにしました。クライアントでは、評価用の制御トラフィックを生成する自動スクリプトを実行しました。各反復処理では、VPNクライアントアプリケーションを起動し、Pywinautoを使用して「デフォルト/推奨」サーバーに接続しました。20～180秒のランダムな待機時間の後、VPNトンネルがアクティブであることを確認し、Alexaトップ500からランダムなウェブサイトにリクエストを送信することで、Seleniumを使用してランダムなブラウジングトラフィックを生成しました。最後に、VPNサーバーから切断し、180秒間待機してから、次の反復処理に進みました。VPN構成ごとに、このプロセスを50回繰り返し、参照用にパケットキャプチャを収集しました。

詳細な内容

OpenVPNプロトコル

OpenVPNは2002年に初めてリリースされ、標準のTCPとUDP上で無料で高速でありながら、セキュリティに重点を置いたトンネリングプロトコルを作成することを目的としていました。OpenVPNトンネルがアクティブになると、トンネルから最終的な宛先へ、または最終的な宛先からトンネルへ送信される生のIPパケットは、OpenVPNパケット内にカプセル化されます。安全な通信を実現するために、OpenVPNはOpenSSLライブラリを暗号化層として活用しています。ピアとの信頼関係を確立するために、事前共有静的鍵またはTLSベースのネゴシエーションという2つの認証および鍵交換方法が提供されています。後者は、商用VPNサービスの大多数で採用されています。鍵交換とデータ転送には、それぞれ別々のチャネルが使用され、両方のチャネルが単一の多重化されたTCP/UDPストリームを共有します。制御チャネルでは、クライアントとサーバーがTLSスタイルの鍵素材交換を行います。TLSは信頼性の高いトランスポート上で動作するように設計されているため、OpenVPNは、明示的な確認応答と再送信メカニズムに基づく、シーケンシャルで信頼性の高い層を制御チャネルに提供します。制御チャネルでネゴシエートされた鍵は、データチャネルで転送されるパケットの暗号化に使用されますが、データチャネルは信頼性の保証を提供しません。図1は、完全に暗号化されたデータチャネルに至る、OpenVPNパケットの典型的な初期化シーケンスを示しています。

OpenVPNのフィンガープリンタビリティ

OpenVPNのフィンガープリンタビリティを調査した結果、OpenVPNはバイトパターン、パケットサイズ、サーバー応答などのプロトコル機能に基づいて識別可能であることがわかりました。ネットワークを制御する攻撃者の役割を演じ、パッシブフィンガープリンティングとアクティブプロービングを順番に実行する2段階のフレームワークを設計しました。100万人のユーザーを抱えるISPであるMeritと提携し、Meritの主要なポイントオブプレゼンスからミラーリングされた20 Gbpsのイングレスおよびエグレストラフィックを観測する監視サーバーに、このフレームワークを展開しました。テストでは、ネットワーク内の制御クライアントマシンから発信された2000のフローのうち1718を識別することができ、これは40のユニークな「バニラ」OpenVPN構成のうち39に対応しています。

さらに驚くべきことに、難読化されたOpenVPNフローの3分の2以上も識別することに成功しました。上位10社のプロバイダーのうち8社が難読化サービスを提供していますが、すべてがフィルターによってフラグ付けされています。プロバイダーが「インターネットプロバイダーでさえVPNを使用していることを認識できない」など、観察不可能であるという誇大な主張をしているにもかかわらず、難読化サービスのほとんどの実装は、単純なXOR-PatchでマスクされたOpenVPNに似ており、簡単にフィンガープリンティングできることがわかりました。難読化層でのランダムパディングの不足と、バニラOpenVPNサーバーとのコロケーションも、難読化サービスを検出しやすくしています。

典型的な日には、1台のサーバーで15 TBのトラフィックと20億のフローを分析します。8日間の評価で、このフレームワークは3,638のフローをOpenVPN接続としてフラグ付けしました。そのうち、3,245のフローについて、検出結果を裏付ける証拠を見つけることができました。これは、以前のMLベースのアプローチよりも3桁低い誤検知率の上限を示唆しています。

OpenVPNのフィンガープリンティングにおける課題

現実世界でのVPN検出の課題には、プライバシーの懸念、リアルタイム分析、エンジニアリング上の制約などがあります。フィンガープリンタビリティの効果的な調査には、ISPや検閲機関が実際にどのように運用されているかについての視点を取り入れる必要があります。単にフィンガープリンティングの脆弱性を特定するだけでは不十分です。困難ではありますが、ISPや検閲機関の能力と制約を考慮しながら、脆弱性を悪用することの実用性を示すために、現実的な悪用を実証する必要があります。例えば、以前の学術研究では、フローレベルの機能を使用してVPN検出用のML分類器をトレーニングすることが検討されていました。しかし、これらの検出アプローチがISPや検閲機関にとってどれほど実用的であるかは不明であり、MLベースの検閲システムの現実世界での展開を調査した厳密な研究は知られていません。さらに、以前の研究では、OpenVPNと非VPNのトラフィックがバランスよく含まれているISCXVPN2016データセットを使用してテストが行われています。しかし、現実世界ではVPNトラフィックのベースレートが低いため、最も性能の良いMLシステムであっても、付随的損害に敏感な現実世界の検閲機関にとって経済的に非現実的な誤検知率が発生することに注意する必要があります。

しかし、ISPや検閲機関の観点からの調査は、困難な場合があります。第一に、そのような調査には、現実世界のISPとの協力とそのネットワークトラフィックへのアクセスが必要です。ISPのネットワーク内に監視装置を設置する必要がありますが、分析がISPの通常のルーティング運用に影響を与えないようにする必要があります。さらに、実際のユーザーからのトラフィックを分析すると、倫理的な問題が発生します。生のネットワークデータを処理すると、ユーザー、特に脅威モデルが高いことが多いVPNユーザーのプライバシーが侵害される可能性があります。最後に、アドホックなトラフィック分析をリアルタイムで実行するシステムを展開するには、大きなエンジニアリング上の課題があります。パケット到着率に合わせた分析フレームワーク全体（処理とロギングを含む）の構築と、非対称ルーティングやパケット損失が分析と結果に及ぼす影響を考慮する必要があります。

OpenVPNの検出手法

1. オペコードベースのフィンガープリンティング

図3に示すように、各OpenVPNパケットには、TCPモードでは24ビット、UDPモードでは8ビットのヘッダーがあり、これは暗号化されたペイロードの一部ではありません。各OpenVPNヘッダーは、現在のパケットのメッセージタイプを指定するオペコードと、（新しい）TLSセッションを参照するキーIDで始まります。オペコードフィールドは、10以上の定義された値を取ることができ、それぞれ異なる通信段階で送信されるメッセージタイプに対応しています。典型的なOpenVPNセッションは、クライアントがクライアントリセットパケットを送信することから始まります。次に、サーバーはサーバーリセットパケットで応答し、TLSハンドシェイクが続きます。TLS暗号文を運ぶOpenVPNパケットは、メッセージタイプとしてP_Controlを持ちます。OpenVPNはUDP上で動作できますが、TLS用の信頼性の高いチャネルを提供する必要があるため、各P_ControlパケットはP_ACKパケットによって明示的に確認応答されます。最後に、実際のペイロードはP_Dataパケットとして送信されます。図1は、オペコードの注釈付きでこのパケット交換を示しています。

固定数の値を取るパケットフィールドは、フィンガープリンティングが容易であり、他のプロトコルに対して以前に悪用されたことがあります。フローの最初のN個のパケットの各オペコードバイトを分析することで、OpenVPNのハンドシェイクシーケンスをフィンガープリンティングします（しきい値Nについてはセクション7.2で検討します）。アルゴリズム1は、オペコードフィンガープリンティングのプロセスを示しています。オペコードは、特定のフローの最初のN個のパケットで見つかったN個のオペコード値のシーケンスを指します。簡単に言うと、フィルターは、観察された異なるオペコードの数がプロトコルと一致し、ハンドシェイクが完了した後、クライアントリセットとサーバーリセットが1度も見られない場合に、フローにフラグを立てます。

以前の研究や既存のオープンソースDPIでは、プロトコル仕様に基づいてオペコード値とパケットサイズを静的に照合することが検討されていました。これとは対照的に、**本レポートでは、OpenVPNセッションの確立を反映した、オペコード値の変動を動的に捉えることを提案します。**特に、このヒューリスティックは、オペコード値やパケット長を完全に一致させる必要はありません（例えば、最初のパケットの3番目のバイトが0x38である必要はありません）。これにより、XORで難読化されたフローに対して効果的に機能することが保証されます。XOR難読化は、パケットペイロードをマスクして、オペコードバイトが変更されるようにします。特に、仕様によると、難読化手順の1つとしてパケットを反転させる場合、図4に示すように、バッファーの最初の文字（オペコードバイトがある場所）は反転から除外されます。そのため、オペコードバイトは常にXORキーの同じバイトとXOR演算され、難読化後も同じオペコードが同じ値にマッピングされます。この動作は、Tunnelblick（これまでに見られたユニークなオペコードの数、ヒューリスティックはより柔軟であり、OpenVPNのさまざまなXORベースの難読化を対象としています）を使用する場合も維持されます。

2. ACKベースのフィンガープリンティング

OpenVPNは、制御チャネルを介してピアとのTLSスタイルのハンドシェイクを行います。TLSは信頼性の高い層上で動作するように設計されているため、OpenVPNは、制御チャネルメッセージの明示的な確認応答と再送信メカニズムを実装しています。具体的には、着信P_-ControlパケットはP_ACKパケットによって確認応答されます。P_ACKパケットはTLSペイロードを運ばず、サイズは均一です（これらのACKパケットはペイロードとしてTCPによって運ばれ、TCP ACKフラグと同じではありません）。さらに、これらのACKパケットは、ほとんどの場合、フローの初期段階、つまりハンドシェイクフェーズでのみ見られ、信頼性の低い層上で動作できる実際のデータ転送チャネルでは使用されません。

本レポートでは、OpenVPNに対して、プロトコル層の明確なACKに基づくフィンガープリンティングを試みるのは初めてです。以前は、meekのTCPレベルのACKトラフィックにおける独特のタイミングパターンにより、難読化ツールが検出されることがありました。OpenVPNの場合、明示的なACKパケットが存在し、サイズが均一で、セッションの一部でのみ見られるということが、もう1つのフィンガープリンティング可能な特徴を提供します。具体的には、まず、図1に示すように、C->S（クライアントリセット）、S->C（サーバーリセット）、C->S（ACK）、C->S（制御）という初期パケット交換シーケンスを見つけることで、セッションのACKパケットと思われるものを特定します。バニラOpenVPNとXORベースの難読化の場合、最初のACKパケットは通常、セッションで送信される3番目の（データ）パケットとして表示されます。独自のハンドシェイクまたは鍵交換プロセスを持つトンネルまたは難読化器（Stunnel、SSHトンネル、Obfsproxyなど）の場合、このカウントはトンネルハンドシェイクパケットの数だけオフセットされます。次に、パケットを10パケットのビンにグループ化し、特定されたACKパケットと同じサイズの各ビン内のパケット数をカウントすることで、各フローのACKフィンガープリントを導き出します。OpenVPNフローの場合、初期のビンでは多数のACKパケットが観察され、後期のビンでは観察されないことが予想されます（セッションの後半では、ランダムな鍵素材を転送するためにControlパケットとACKパケットが再び交換されることがありますが、観察ウィンドウN内では観察されないと予想されます）。このアプローチは、バニラOpenVPNと、ランダムパディングがない暗号化トンネル上で実行される難読化サービスのフィンガープリンティングに効果的であることが証明されています。セクション7.1では、正確なフィンガープリンティングのしきい値を定量化しています。

3. アクティブプロービング

通常、OpenVPNサーバーはクライアントリセットに対して明示的なサーバーリセットで応答するため、アイデンティティが明らかになります。しかし、現在、ほとんどの商用プロバイダーは、tls-authまたはtls-cryptオプションを採用しています。これらのオプションは、初期リセットパケットを含む、すべての制御チャネルパケットに、事前共有鍵で署名された追加のHMAC署名を追加して、整合性を検証します。これらのオプションのいずれかを有効にすると、OpenVPNサーバーは、認証されていないクライアントリセットに対してサーバーリセットで応答せず、代わりにそのようなパケットをさらに処理することなくドロップします。このようなHMACメカニズムの存在は、アクティブプロービングの実行を複雑にします。認証されていないクライアントによってプローブされたときに沈黙を保つことで、OpenVPNサーバーを効果的に「プローブ耐性」にします。

実際、同様のHMACメカニズムは、obfs4などの、より一般的な「プローブ耐性」プロキシで使用されています。ただし、認証されていない接続をドロップする前にサーバー固有のランダムな遅延を待つobfs4とは異なり、OpenVPNは有効なHMACが見つからない場合は常にすぐに接続を閉じます。このプローブは、このプロトコル固有の動作を活用するように設計されており、その結果、プロービングサイクル全体で応答しなくても、OpenVPNサーバーをフィンガープリンティングすることができます。重要な概念は、アプリケーションがプロービングに応答しない場合でも、攻撃者は、Frolovらによって実証されたように、タイムアウトやRSTしきい値などのTCPレベルでアプリケーション固有のしきい値をフィンガープリンティングできる可能性があるということです。

4. パケット長ベースのフィンガープリンティング

OpenVPNはパケット長を検証し、無効な長さを送信する接続を次のパケットが再構成されるのを待たずにドロップするという事実に基づいて、追加のプローブを設計します。ここで、パケット長とは、TCPパケット長ではなく、OpenVPNヘッダーの最初の2バイトで宣言された長さを指します（図3を参照）。「有効な」長さは[1, max_len]の範囲内です。max_lenはサーバーのMTU構成から導き出されます。例えば、デフォルトのTUN MTU 1500バイトにオーバーヘッド（暗号IV、パケット長など）を組み合わせると、max_lenは1627バイトになります。この場合、最初の2バイトが1627（0x06,0x5B）より大きい10進値を持つプローブは、すぐにドロップされます。

5. RSTしきい値ベースのフィンガープリンティング

LinuxサーバーがTCP接続を閉じる方法を利用したプローブも設計します。TCP接続が終了すると、通常、両端のオペレーティングシステムはFIN 4ウェイハンドシェイクを完了します。しかし、以前の研究では、バッファーに未読バイトがある状態で接続が閉じられた場合、LinuxはRSTパケットを送信することがわかっています。サーバーの「RSTしきい値」は、RSTをトリガーするためにサーバーに送信する必要がある最小バイト数として定義されます。ZMapセットとCensysセットの両方について、RSTしきい値の分布を調べます。図6に示すように、OpenVPNサーバーの大多数は、典型的なMTU構成で割り当てられたバッファーに対応する、約1550～1660バイトのRSTしきい値を持っています。これとは対照的に、ランダムなZMapエンドポイントの97％以上は、RSTしきい値が500未満または4000を超えています。そのため、2,000のランダムバイトを持つ追加のプローブを構築しました。これは、正当なOpenVPNサーバーの98％以上、ランダムサーバーの3％未満がRSTパケットで応答すると予想されます。

難読化されたOpenVPNサービスの脆弱性

商用VPNプロバイダーの大多数は、OpenVPNトラフィックを識別しにくくするために、難読化と呼ばれる手法を採用しています。これらの難読化されたVPNサービスは、しばしば「不可視」で「ブロック不可能」と宣伝されていますが、本レポートの調査では、これらのサービスの多くが検出に対して脆弱であることが明らかになりました。その主な理由は以下のとおりです。

• XORベースの難読化への依存: 調査した上位5社のVPNプロバイダーのうち4社は、難読化サービスを提供していますが、それにもかかわらず、フィルターによって90％以上の確率でOpenVPNフローとしてフラグ付けされています。生のパケットキャプチャを詳しく見ると、すべて非公式のXORパッチとほぼ同じ難読化を採用していることがわかり、フィンガープリンティングに対して脆弱になっています。XORベースの難読化は、OpenVPN開発者によって拒否されていますが、テストしたVPNプロバイダーの大多数が採用している主要な難読化戦略のようです。これらのプロバイダーは、XORパッチのシンプルさと低オーバーヘッドをしばしば賞賛しています。このパッチは、既存のオープンソースDPIツールで採用されている最も基本的なフィルターの一部をバイパスできますが、少し洗練されたフィルターであれば、確実に正確に検出できることが実証されています。
• ランダムパディングの不足: 難読化戦略としてもう1つよく使われるのは、トンネルベースのものです。これは、OpenVPNトラフィックを暗号化されたトンネル内にラップして、パケットペイロードに対する分析を阻止します。例としては、Stunnel、SSHトンネル、Shadowsocks、obfs{2/3/4}、V2Ray(VMess)などがあります。全体として、14のVPNプロバイダーが展開している20の難読化構成がトンネルベースであることがわかりました。しかし、これらのトンネルのほとんどは、トンネリングされるペイロードにランダムパディングを追加しません。唯一の例外は、特定の分布からパケットサイズを取得できるobfs4とVMessです。20のトンネルベースの難読化サービスのうち、obfs4を展開しているのは3つだけで、VMessを展開しているのは1つだけです。残りの16はACKフィンガープリンティングに対して脆弱です。これは、これらのトンネリングツールが機能しないという意味ではなく、トラフィック分析に対する保護が設計目標に含まれていないという意味です。例えば、Perfect Privacy VPNによって展開されているobfs3の脅威モデルでは、難読化器は「パケットサイズやタイミングなどの、コンテンツ以外のプロトコルフィンガープリントに対する保護は試みない」と述べています。しかし、OpenVPNのようにパケット長に明確な特徴を持つアプリケーションの場合、最も単純なしきい値ベースの検出でも、妥当な精度で識別できることが実証されています。
• バニラTCPサーバーとのコロケーション: UDPと難読化されたOpenVPNサービスの大多数は、バニラTCPサーバーとコロケーションされていることがわかりました。例えば、TorGuardは、同じホストの異なるポートでバニラとstunnelで難読化されたOpenVPNインスタンスをホストしていますが、Perfect Privacyは隣接するIPでホストしています（バニラの場合は*..193.26、Stunnelの場合は*..193.27、SSHの場合は*..193.28、obfs3の場合は*..193.29）。41の難読化サービスのうち34については、サーバーの/29サブネット内に少なくとも1つのバニラOpenVPN TCPサーバーが見つかりました。同様に、20のUDP構成のうち18については、TCPサーバーとのコロケーションにより、アクティブにプローブすることができました。さらに、5つのプロバイダーが、難読化されたサービスで使用されているインフラストラクチャを共有していることもわかりました。例えば、1つのIP（23.95..）は、CryptostormのSSHで難読化されたサービスと、SecureVPNのバニラサーバーをホストしています。この結果は、各プロバイダーが利用可能なすべてのサーバーに接続したわけではないため、下限にすぎません。共有インフラストラクチャを使用する難読化サービスは、敵対者が識別してブロックするのが容易かもしれません。

緩和策

本レポートで説明したフィンガープリンティング攻撃から保護するための防御戦略はいくつかあります。

短期的な緩和策

• バニラサーバーと難読化サーバーの分離: バニラOpenVPNサービスと難読化されたOpenVPNサービスの両方を提供しているVPNプロバイダーは、それらをコロケーションしないようにする必要があります。理想的には、難読化サーバーは、ネットワークアドレス空間内のOpenVPNインスタンスから十分に分離し、クライアントトラフィックを他の場所にあるVPNサーバーに転送する「ブリッジサーバー」として動作する必要があります。例えば、Mullvad VPNは、Shadowsocksベースの難読化サービスを専用のブリッジとして提供し、VPNサーバーと難読化を分離しています。
• ランダムパディングの使用: VPNプロバイダーは、難読化サービスに静的パディングではなくランダムパディングを使用する必要があります。本レポートで示したように、安定した特徴的なハンドシェイクフェーズを持つプロトコルの場合、最も基本的なしきい値ベースの検出器でも、パケットサイズによってフィンガープリンティングすることができます。理想的には、難読化層は、ゼロ長パケット（ペイロードがすべてパディングであるパケット）を送信して、難読化されていないパケットストリームと難読化されたパケットストリームの1対1の対応関係を崩すことができる必要があります。しかし、以前の研究では、完全にランダム化された難読化器（obfs4など）でさえ、エントロピーベースのフィンガープリンティング攻撃に対して脆弱である可能性があることが示されています。
• サーバー応答の多様化: OpenVPN開発者は、失敗したハンドシェイクの試みにサーバーがどのように応答するかについて、以前の研究からの推奨事項に従うことをお勧めします。失敗した接続をすぐに、または予測可能な方法で閉じるサーバーは、さまざまな他のプロトコルに対するアクティブプロービング攻撃を可能にしてきました。これに対応して、これらのプロトコルは、無制限のタイムアウト（バッファーから無期限に読み取る）または多様なクローズ動作（各サーバーインスタンスが失敗した接続を異なる方法で閉じる）を実装しています。

長期的な防御

長期的に見ると、グレートファイアウォールとTorのような検閲機関と迂回ツールの間のいたちごっこが、VPNエコシステムでも発生するのではないかと懸念されます。開発者とプロバイダーは、敵対者の進化に合わせて難読化戦略を適応させる必要があります。商用VPNプロバイダーは、Pluggable Transportsなどの、より標準化された難読化ソリューションを採用し、難読化サービスで使用されている技術について、より透明性を高めることをお勧めします。この透明性により、より強力な難読化方法の開発が促進され、開発者が情報制御技術の進歩を克服するためのより良い技術を設計することが奨励されます。VPN難読化のさまざまなアプローチのパフォーマンスコストを特徴付け、脅威モデルが異なるユーザーがパフォーマンスと回復力のある観察不可能性の間で適切なトレードオフを行うのを支援するために、さらなる今後の研究が必要です。

まとめ

本レポートでは、広く適用されている難読化技術を採用したOpenVPNでさえ、ネットワークベースの敵対者によって確実に検出およびブロックできることを実証しました。以前の現実世界の検閲イベントから着想を得て、パッシブフィルタリングを実行し、その後にアクティブプロービングを実行してOpenVPNフローをフィンガープリンティングする2段階システムを設計しました。中規模のISPと提携してアプローチの実用性を評価した結果、ごくわずかな誤検知でバニラおよび難読化されたOpenVPNフローの大部分を識別することができました。これは、説明した手法が、付随的損害を嫌う敵対者にとっても実用的であることを裏付けています。

世界中のユーザーは、セキュリティとプライバシーを保護し、インターネット検閲を回避するためにVPNに依存していますが、OpenVPNトラフィックのフィンガープリンティングの容易さとDPI技術の普及により、一般的なVPNサービスの監視とブロックが、ほぼすべてのネットワーク事業者の手の届くところに来ています。本レポートでは、これらの脅威から防御するのに役立ついくつかの短期的な緩和策を提案していますが、長期的に見ると、VPNプロバイダーは、より回復力のある、より標準化された難読化アプローチを採用することをお勧めします。