xTLS Vision TLS in TLS 星とその先へ

Networks

簡単に言えば XTLS

XTLS のコア ロジックは、実際の TLS を使用して、インターネット上の最も一般的なトラフィックの中にプロキシ トラフィックを隠すことです。通常の TLS プロキシ プロトコル (元のTrojanなど) の場合、ユーザーのプロキシ クライアントは、プロキシ サーバーとの実際の TLS 接続を確立します. この暗号化されたトンネルを介して、アプリケーション (ブラウザーなど) は、ターゲット サーバー (そのようなサーバー) との TLS 接続を確立します。 Google として）接続します。現時点では、ブラウザと Google サーバーはエンド ツー エンドで暗号化されており、誰も (プロキシ サービスを含めて) 送信された情報を解読したり偽装したりすることはできません。

ブラウザ ---- プロキシ クライアント ==== プロキシ サーバー ---- Google

プロキシ データは実際には検閲を通過するときに 2 回暗号化されますが、RPRX は、このプロセスのトラフィックの 99% が追加の暗号化を必要としないことを痛感しました。TLS 1.3 で暗号化されたデータは外見が同じであるため、検閲官は違いを見分けることができません。つまり、プロキシ ロジックは次のことだけを行う必要があります

  1. 実際の TLS 接続を確立する
  2. 暗号化されたトンネル内で、ブラウザと Google の間の通信を追跡して、現在の通信が TLS 1.3 であるかどうかを識別します
  3. そうでない場合は、通常の TLS プロキシ メソッドを使用し、暗号化されたトンネルを引き続き使用します。
  4. その場合、両端が暗号化されたデータの送信を開始するのを待ち、プロキシ クライアントは最初の内部暗号化パケットに UUID を挿入し、プロキシ サーバーに次のように示します。
  5. 2番目の内層暗号化パケットの後、XTLS はデータ パケットに対して何の操作も行わず、単にコピーするだけです。

これがxtls-rprx-vision

私たちは見つけることができます

  1. プロキシによって開始された外部 TLS は本物であるため、検閲者はそれをクラックできません
  2. ストリーキングトラフィックはプロキシ側で単純にコピーされ、検閲者が何らかの損害を与えると、通常のアクセスと変わらないブラウザと Google サーバーから通常のアラート応答が返されます
  3. ストリーキングのシグナルはエージェントの個人情報である UUID であり、 23 3 3 判定部のコード特性の悪用と同様の Go#17の脆弱性を回避するためのものです。

ほぼ完璧

10 月 3 日、TLS プロキシの大規模な識別とブロックが開始されました.関連するいくつかの議論とインサイダー情報を通じて、検閲が膨大なリソースと機械学習手法を使用したことがわかりました. ご存知のように、機械学習の専門分野は、大量のデータから統計的特徴を抽出することにあります。klzgrad を引用する
と、一般的な TLS プロキシの重要な弱点は、暗号化された入れ子人形です。前述のように、暗号化されたパッケージの外観はレビュアーには区別がつきませんが、暗号化された人形の必然的なポイントは、各パケットにデータ パケット ヘッダーが追加されることです. 暗号化レイヤーが増えるほど、パケット ヘッダーは重くなります. この増加は大きくはありませんが、小さなデータ (応答パケットなど) の場合はより明白になる可能性があり、一部のパケット長は基盤となるネットワークの MTU 制限を超えます。最も重要なことは、各パケットが同じ長さで増加するため、いくつかの統計的特性を持つ可能性があることです。

当時 RPRX が XTLS を発明した主な理由は、追加の暗号化を減らすことでした. XTLS には検閲に抵抗する独自の機能があるため、現在、新しいフロー制御ビジョンを開始しています. TLS 1.3 データを送信する場合、XTLS 99% のデータ パケットはほぼ完全なトラフィック特性を備えていると言えます。プロキシ処理なしの生データなので。

TLS in TLS

パケットの 99% が生データであると言われているのはなぜですか? その1%って具体的に何？
内部 TLS 1.3 トラフィックに遭遇したときに、典型的なプロキシが最初の数パケットで何をするかを調査し続ける必要があります。
視覚的に、暗号化されたチャネルが確立されると:

1番目のパッケージ プロキシ クライアント -> プロキシ サーバー 「こんにちは、このプロキシ アクセスのターゲット アドレスは Google です。これが私の UUID です」
2番目のパッケージ Proxy Client <- Proxy Server 「こんにちは、プロキシ要求を受け取りました。データの送信を開始してください」
3番目のパッケージ Browser -> Proxy Client -> Proxy Server -> Google 「Hi Google, I will make a encrypted call with you.The encryption methods I support are...」 (このパッケージは TLS Client Hello とも呼ばれます)
4番目のパッケージ ブラウザ <- プロキシ クライアント <- プロキシ サーバー <- Google
5番目のパッケージ ブラウザ -> プロキシ クライアント -> プロキシ サーバー -> Google 「受信しました 暗号化された通話を開始しましょう!」

ユーザーが任意の TLS 接続を使用している限り、既知のプロキシ プロトコルは変わりません。上記のハンドシェイク プロセスが必要です。前述のように、TLS 暗号化の外側の層は完全に安全であると見なすことができますが、レビュアーにとっては、情報のクラックに加えて、いくつかの追加情報を使用して 5 つのパッケージを識別することができます。
これは、TLS 検出におけるいわゆる TLS のキー ポイントです。

生と死 5パッケージ

最も明白な特徴は、これら 5 つのパケットの長さです

1番目のパケットは短く、唯一の変数は宛先アドレスです
2番目のバッグは非常に短く、ほぼ固定されています
3番目のパッケージは短く、ほとんど変化しません。ほぼ唯一の変数はターゲット SNI です。
4番目のパッケージの長さが大きく変わります
5番目のバッグは非常に短く、ほとんど変化しません

それらのパケット長特性は実際には非常に明白であることが直感的に感じられます。Vision でのソリューションも非常にシンプルで、各ショート パケットの長さを 900 から 1400 の範囲に収めます。この方法は従来のランダム パディングとは異なることに注意してください. すべてのパケットにやみくもにパディングを追加するわけではありませんが、内部トラフィックの分析に基づいて、TLS ハンドシェイク プロセスのアイコン パケットに対象を絞ったパディングを実行します

もう 1 つのより微妙な機能は、タイミング機能と呼ばれます。TLS ハンドシェイクの設計による制限により、最初のいくつかのパケットの順序が固定されていることがわかります。つまり、ブラウザーが TLS Client Hello を送信した後、Google が TLS Server Hello メッセージを送信するのを待つ必要があります。その後、ブラウザーは「受信しました。暗号化された通話を開始しましょう!」というメッセージを送信する必要があります。正常な動作である可能性があります。
ユーザーがパケットをサーバーに送信する場合、それは C と呼ばれ、反対方向のパケットは S と呼ばれます。審査官は、CSCSC データの時系列とその時間間隔の特性に基づいて、これが TLS 接続の TLS であると判断できますか?
以下の結論を出すだけでは十分ではないと考えており、Vision はこの側面を扱っていません。
多くの開発者は、TLS 検出での TLS に対する MUX 多重化について言及しています。2 つの異なる TLS 接続がトンネル内で多重化されている場合、CCSSCC などのさまざまなタイミング特性が形成される可能性があります。

壁を回避する技術戦争は、今後もシャドーソックス(暗号化)→能動的検知→TLS→機械学習と進化していくことが予想されるが、生き残るか死ぬかは、この5つのパッケージの処理に大きく依存することになるだろう。

よくある質問

Q: Vision のパディングの長さはハードコーディングされていますが、統計的特性もありますか?

A:まず第一に、ネットワーク セキュリティの概念に絶対的なセキュリティはありません. 理論的には、あらゆる暗号化は力ずくで破ることができますが、計算の量 (投入されたリソース) はそれ以上のものではありません. セキュリティ プロトコルの設計者として、クラッキングと識別の難しさを検閲の手の届かない高さにまで上げればよいのですが、この高さはどのくらいですか? 戦争を見るまで分からないのではないかと心配しています。
既知の情報に戻ると、TLS 1.2 および 1.3 ハンドシェイク パケットの長さの分布は非常に安定しています。メインストリーム サイト (Google など) にアクセスするいくつかのキー パケットは、固定長と見なすことができます。Vision の既存の大きなパケットのランダムな長さをパディングなしのハンドシェイク パケットと比較すると、認識の難易度は桁違いに増加するはずです。
また、いくつかのリークされた議論では、機械学習は 40% 未満のランダムなパディングを識別できることが言及されていました。これは、機械学習の識別に上限があることを側面から証明できます。

Q: 新しい流体制御の名前が Vision である理由は?

A: Vision は RPRX の元の設計コンセプトを表していると考えています。実際、XTLSの最初のバージョンは模索中に開発されたものであり、当時の開発環境によっては制限があり、複雑すぎる場所もありました.Visionは、XTLSの理想的な形と将来の方向性を表していると言えます. RPRX は次のように述べています

Flow.. はどのような問題を解決しますか?これは、暗号化が対処しようとしている微視的なトラフィック タイミング特性ではなく、巨視的なトラフィック タイミング特性に影響します。トラフィックのタイミング特性は、TLS を介した Socks5 中の Socks5 ハンドシェイクなど、プロトコルによってもたらされる可能性があります.TLS 上の異なる特性は、モニターの異なるプロトコルです.現時点では、無制限のスケジューラは無制限のプロトコルと同等です (データが送信されるたびに再配布されます)など）

v2ray/v2ray-core#2636

実際、Direct は TLS ライブラリを魔法のように変更することなく実装できます. TLSv1.3 を送信する場合、読み取りフィルタリングは必要なく、書き込みフィルタリングも必要ありません. 非常に簡潔で効率的です.

XTLS/Go#12 (comment)

Q: 新しいフロー制御は非常に優れていますが、これを使用してファイアウォールをバイパスすることをすべての人にお勧めしますか?

A: 他の開発者が言っているように、現在のレビュアーがすべての卵を 1 つのバスケットに入れるのは非常に危険です。そのため、各ツールの特性を活かし、特性を分散させることを皆様にお勧めします。

Q：sm4などの国家機密は将来的におすすめですか？

A:最初に述べたように、お勧めしません。最も安全な方法は、インターネット上の最も一般的なトラフィックに隠れることだと考えています。HTTPS に加えて、一般的なアウトバウンド トラフィックの種類を考慮する必要があります。SSH? リモートデスクトップ？微信ビデオ？メール（霧）？無線通信（霧）？非常にニッチな暗号化とプロトコルを使用する代わりに。

私たちの視点

実際、TLS ベースのプロキシは 2017 年にかなり成熟しました。2019 年に Shadowsocks サービスが大規模に封鎖されて以来、検閲官は多大な労力、材料、計算能力を投入し、今日の技術を手に入れるまでに少なくとも 3 年はかかったと考えられます。現時点では、ブロックにまだエラーがあることを確認しており、ほとんどの CDN が存続し、IPV6 が存続しています.Xray プロジェクトへの訪問数と、オンライン テレグラム グループの数が新たな高値を記録したという観点から、その効果は今回の情報を遮断する検閲の数は、実際には非常に限られています。

開発サークルの一員として、私たち有志のグループ、Shadowsocks、*ray、Trojan、Naive、Hystaria、Tuic、Sing は、地面の Friction でレビュアーを押し続けてきたといっても過言ではありません

TLS プロキシ戦争は始まったばかりであり、検閲者が AI 手段を使用する理由は、アクティブな検出を含む以前の検閲方法が TLS プロキシに対して無効であることを側から証明するためです。しかし、AI の対戦相手に直面したときは、詳細レベルでよりうまくやらなければなりません。
私たちは強み、ブレインストーミング、オープンソース、分散機能を最大限に活用できます。具体的には、プロキシ ツールおよびサービスとして、内部層のトラフィックを直接フィルタリングできます。これは、検閲に対する私たちの自然な利点です。この情報のギャップを使用して、Vision のロジックは重要な TLS ハンドシェイク パケットを埋めることができます。この考え方は、一部の特定のパッケージに対する NaiveProxy のパディングと一致しています

この記事をお読みいただきありがとうございます. すべてのテクノロジー愛好家からのメッセージをお待ちしております. すべてのメッセージとアイデアは、私たちの戦いの力になります.

ついに@RPRX
緑の山は変わらない 緑の水は永遠に流れる ティーンエイジャーとして戻ってきますように

オリジナル：XTLS Vision, TLS in TLS, to the star and beyond #1295

コメント

タイトルとURLをコピーしました