Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

フィードお問い合わせプライバシー© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
USTP-Secure — USTPの安全な(AEAD対応)バージョンであるUSTP-Secure(ustps://) | Kitploit
ツール/GitHubGitHub/x1colegal/ustp-secure
暗号化/復号化ツールスクリプトと自動化ネットワークセキュリティ暗号化ユーティリティとフレームワーク
GitHubx1colegal/ustp-secure

USTP-Secure

USTPの安全な(AEAD対応)バージョンであるUSTP-Secure(ustps://)

リポジトリを見る
141232ヶ月前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

USTP

USTP は UDP Speedy Transmission Protocol を意味します。

USTP は同じ認証済みトランスポートモデルを維持していますが、プロジェクト名は再び単純に USTP になりました。

デフォルトでは、USTP は DATA に AEAD を使用します。

また、DATA 用のオプションのネゴシエートされた cleartext + HMAC モードもサポートしており、ペイロードのバイトはワイヤ上で可視ですが、改ざんは検出され拒否されます。

USTP は現在、USTP Congestion と呼ばれるオプションの輻輳制御機能をサポートしています。依然として UDP ファーストですが、パスが輻輳の兆候を示し始めたときに、オプションで速度を落とし、その後再び速度を上げることができます。

ステータス: Beta

USTP はもはや単なる概念実証ではありません。現在は Beta フェーズにあります。

USTP はさまざまな種類のアプリケーションやトランスポートに使用できます。

ただし、このリポジトリは特に USTP 上のストリーミング に焦点を当てています。

ニュース

  • 02/08/2026: USTP-Secure は再び USTP に戻りました。
    • USTP-Secure は古いプロジェクト名であり、もはやプロジェクトに適した名前ではありません。
    • 短い USTP という名前が再び好まれるようになりました。
    • 正式名称は UDP Speedy Transmission Protocol となり、タイトルに Secure は含まれません。
  • 2026-07-18: USTP/2 Beta が現在のツリーから削除されました。
    • 実際の環境での動作は、損失下において USTP/1.1 よりも安定性が低いものでした。
    • 現在の安定したトランスポートパスは USTP/1.1 のみです。
    • トランスポートハンドシェイクはプレーンテキストの ASCII レコードを使用するようになりました。

ビルドに関する注意

  • Codex と GPT-5.4 (Low) を使用してビルドされました。
  • --loss 33 でフリーズせずに検証済みです。
  • テストパス: Brazil -> Canada、RTT 約 140ms。

セキュリティモデル

  • トランスポートは UDP のままです(TCP トンネルではありません)
  • AEAD 暗号:
    • chacha20 = CHACHA20_POLY1305
    • aes-256-gcm = AES_256_GCM
    • aes-128-gcm = AES_128_GCM
  • デフォルトの AEAD 暗号: chacha20
  • デフォルトの DATA 保護モードは AEAD です。
  • オプションの DATA 保護モードは cleartext + パケットごとの HMAC です。
  • cleartext モードでは、ペイロードのバイトは暗号化されませんが、変更は検出され、無効なパケットは破棄されます。
  • トランスポート制御パケット(HELLO、ACK、RETRANSMIT_REQUEST、CLOSE)は意図的にプレーンテキストのままです。
  • 制御パケットは ASCII トランスポートレコードとしてシリアライズされます。
  • ACK と NACK/RETRANSMIT_REQUEST はプレーンテキストのままですが、セッションごとの HMAC タグで認証されます。
  • これにより、セキュアセッションが確立された後に、オフパスから偽造された ACK/NACK 制御パケットが ACK 攻撃や再送 DoS を引き起こすことを防ぎます。
  • DATA パケットは UPACK(ワイヤ上では UPAK)という名前のバイナリフレーム形式を使用します。
  • 静的 PSK は使用されません。
  • 各クライアントは参加時に X25519 鍵交換を実行します。
  • 各クライアントは個別の AEAD セッションキーを取得します。
  • サーバーは複数のクライアントをサポートします。
  • サーバーは送信元の IP:port でチャレンジのラウンドトリップを行い、クライアントを検証します。
  • サーバーで --cipher が設定されている場合、サーバーはその正確な暗号を使用します。
  • --cipher が省略されているか auto に設定されている場合、サーバーはクライアントが要求した暗号を使用します。
  • クライアントは予期しない暗号ネゴシエーションを拒否します。
  • DATA 保護モードは暗号の選択とは別にネゴシエートされます:
    • サーバー: --cleartext auto|on|off
    • クライアント: --cleartext on|off
    • サーバーのデフォルト: auto
    • クライアントのデフォルト: off
  • サーバーが auto の場合、サーバーはクライアントの要求に従います。
  • サーバーが on の場合、サーバーは cleartext + HMAC を強制します。
  • サーバーが off の場合、サーバーは AEAD を強制します。
  • TOFU(Trust On First Use)はクライアントで有効になっており、初回接続後の予期しないサーバーキーの変更を検出します。
  • サーバーはデフォルトで ~/.ustps_host_key に永続的な X25519 ホストキーを保持するため、TOFU は再接続や再起動をまたいでも安定したままです。
  • 通常のサーバー再起動ではホストキーは変更されません。
  • そのホストキーを意図的にローテーションしたい場合にのみ、サーバーで --regen-key を使用してください。

パケットマジック値

  • ACK:、NACK:、HELLO:、CLOSE: は平文制御レコードのプレフィックスです。
  • USS1 は UDP Speedy Secure バージョン1を意味します。
  • USC1 は UDP Speedy Clear バージョン1を意味します。
  • UPAK はバイナリ UPACK DATA フレームのマーカーです。
  • USTP では、平文制御は ACK: 10、NACK: 42、HELLO: ...、CLOSE: のような人間が読める ASCII です。
  • USTP では、UPAK は復号後のバイナリ DATA パケットを識別します。
  • USTP では、USS1 は外側のセキュアな AEAD エンベロープ形式です。
  • USTP では、USC1 は外側の平文+HMAC DATA エンベロープ形式です。
  • したがって、ワイヤ上では通常次のように見えます:
    • USS1... は AEAD で保護された DATA
    • USC1... は平文+HMAC の DATA
    • トランスポート制御用の可読な制御行

トランスポートモデル

  • USTP はオプションの USTP Congestion を有効にして動作でき、ハンドシェイク中にネゴシエートされます。
  • パケットはトランスポートの seq とアプリケーション向けの stream_pos の両方を運びます。
  • seq は ACK、損失検出、再送、および RTT サンプリングに使用されます。
  • stream_pos はペイロードが論理バイトストリームのどこに属するかをアプリケーションに伝えます。
  • 現在の実装では、seq は各新規セッションで 1 から始まる32ビットカウンタです。
  • 現在の実装では、stream_pos は各新規論理ストリームで 0 から始まる64ビットのバイトカウンタです。
  • 受信側は、1つの欠落パケットの後ろで配信をブロックするのではなく、パケットを即座に受け入れます。

ハンドシェイクとセッションモデル

  • クライアントは、自身の X25519 公開鍵、要求暗号、要求輻輳制御モード(on または off)、および要求 DATA 保護モード(cleartext on|off)を運ぶ平文トランスポート HELLO から開始します。
  • サーバーはメディアをすぐには送信しません。最初に以下を含む平文チャレンジを送信します:
    • ランダムなリトライトークン
    • 生成された Base64 の session_id
    • 選択された暗号
    • ネゴシエートされた輻輳制御モード
    • ネゴシエートされた DATA 保護モード
    • サーバー公開鍵
  • クライアントは、そのまったく同じトークンとセッションメタデータで応答しなければなりません。
  • そのトークンのラウンドトリップが成功した後にのみ、サーバーはセッションを作成し、DATA の送信を開始します。
  • 検証後、セッションはチャレンジを完了した送信元 IP:port にバインドされます。
  • session_id は依然としてセッションラベルとして使用されますが、異なる IP:port からは受け入れられません。

リトライトークン

  • USTP は、暗号化されたメディアセッションが受け入れられる前に、平文のリトライトークン手順を使用します。
  • フロー:
    • クライアントが HELLO を送信
    • サーバーが token、session_id、選択された暗号、ネゴシエートされた輻輳制御モード、ネゴシエートされた DATA 保護モード、およびサーバー公開鍵を運ぶ USTPS-CHALLENGE1 で応答
    • クライアントがそのトークンを USTPS-CHALLENGE-REPLY1 でエコーバック
    • その後にのみ、サーバーはセッションを作成し、USTPS-SESSION1 を送信
  • 目的:
    • その送信元 IP:port にいる送信者が実際にそこでパケットを受信できることを証明する
    • 検証されていない送信元アドレスに暗号化メディアを即座に送信することを避ける
    • 最終的なセッション作成をラウンドトリップを完了したエンドポイントにバインドする
  • リトライトークンはセッションキーではありません。
  • それは実際の USTP セッションが作成される前の到達性証明およびハンドシェイクゲートにすぎません。
  • また、ノンスとしても使用されず、単独で ACK/NACK MAC キーとしても使用されず、パケットペイロード状態として再利用されることもありません。

歴史的なプロトコル識別子

  • プロジェクト名は現在 USTP ですが、いくつかのワイヤ上の ASCII 識別子は依然として歴史的な USTPS-* プレフィックスを使用しています。
  • これは既存の実装、キャプチャ、ログ、および古いデプロイメントとの後方互換性のために意図的なものです。
  • 現在の実装では、以下の制御識別子がワイヤ上に残っています:
    • USTPS-KEX1
    • USTPS-CHALLENGE1
    • USTPS-CHALLENGE-REPLY1
    • USTPS-SESSION1
    • USTPS-RESUME1
    • USTPS-RTT1
  • プロジェクト/ドキュメント名は USTP に戻りましたが、それらの歴史的なワイヤ識別子はプロトコルバイト内で改名されていません。

MTU、PMTU、フラグメンテーション

  • 現在の UPACK DATA ペイロード上限: 900 バイト。
  • UPACK 固定ヘッダー: 20 バイト。
  • AEAD モードにおける外側 USS1 セキュアエンベロープのオーバーヘッド:
    • 4 バイトのマジック
    • 1 バイトの暗号ID
    • 12 バイトの AEAD ナンス
    • 16 バイトの AEAD タグ
  • したがって、暗号化された USTP DATA データグラムは UDP/IP ヘッダーを除いて約 953 バイトです。
  • クリアテキストモードにおける外側 USC1 クリアテキストエンベロープのオーバーヘッド:
    • 4 バイトのマジック
    • 16 バイトの HMAC タグ
  • したがって、クリアテキストの USTP DATA データグラムは UDP/IP ヘッダーを除いて約 940 バイトです。
  • IPv4 + UDP ヘッダーを含めると、AEAD モードではワイヤ上で約 981 バイト、クリアテキストモードでは約 968 バイトになります。
  • IPv6 + UDP ヘッダーを含めると、AEAD モードではワイヤ上で約 1001 バイト、クリアテキストモードでは約 988 バイトになります。
  • USTP は現在、トランスポートレベルのフラグメンテーションを実装していません。
  • USTP は現在、PMTU ディスカバリを実装していません。
  • 実装では代わりに、固定の保守的なペイロード上限を使用しています。
  • それでも下位層で IP フラグメンテーションが発生し、1つのフラグメントが失われた場合、UDP データグラム全体が失われ、USTP は通常の選択的再送によってそれを回復します。

古いパケットと重複パケット

  • 現在のセッション内の重複パケットは、その seq がすでに受理された後は無視されます。
  • 非常に古いパケットは受信側の履歴ウィンドウから外れて古いものとして無視されることがあります。
  • 再送バッファからすでに退役したデータに対する古い ACK/NACK パケットは無視されます。
  • 古い制御パケットが、送信側ですでに完了したパケットを再生成することはありません。

ナンスの挙動

  • DATA の暗号化では、暗号化パケットごとに新たなランダムな 12 バイトの AEAD ナンスを使用します。
  • ナンスはランダムに生成され、seq から導出されるものではありません。
  • 同じセッションキーでのナンスの再利用は禁止されています。
  • seq はトランスポートの信頼性のためのものです。
  • stream_pos はアプリケーションの論理的な順序付けのためのものです。
  • nonce は AEAD パケット保護のためだけに使用されます。
  • クリアテキスト+HMAC モードでは、DATA に AEAD 暗号化を使用しないため、AEAD ナンスは使用しません。

USTP 輻輳制御

  • USTP Congestion はオプションです。
  • これは USTP を順序付きトランスポートに変えるものではなく、TCP スタイルの HoL ブロッキングを追加するものでもありません。
  • 送信側がネットワークにパケットを注入する積極性だけを変更します。
  • ネゴシエーションモデル:
    • サーバー: --congestion-control auto|on|off
    • クライアント: --congestion-control on|off
  • デフォルトの挙動:
    • サーバーのデフォルトは auto
    • クライアントのデフォルトは off
    • サーバーが auto の場合、サーバーはクライアントの要求に従います
    • サーバーが on の場合、クライアントが off を要求しても輻輳制御は強制的に有効になります
    • サーバーが off の場合、クライアントが on を要求しても輻輳制御は強制的に無効になります
  • 実行時の挙動:
    • 通常の送信レートから開始します
    • 経路が健全な間は、実効送信ウィンドウとバーストサイズを徐々に増加させます
    • 計測された RTT、再送タイムアウトイベント (RTO)、および明示的な再送要求 (NACK) を監視します
    • RTT が膨張したり、RTO が発生し始めたり、損失/再送の負荷が上昇したりすると、バックオフします
    • 経路が再び安定すると、ゆっくりと再び増加させます
  • 送信側は依然として、欠落パケットに対してのみ選択的再送を使用します。
  • USTP Congestion はレートの負荷を制御するものであり、信頼性のセマンティクスを制御するものではありません。

ネットワーク変更のサポート

  • この実装から自動ネットワーク/パス移行は削除されました。
  • クライアントがネットワークを変更し、その送信元 IP:port が変わった場合、現在のセッションは終了するものと想定され、クライアントはクリーンに再接続すべきです。
  • 移行の実装が削除されたのは、実運用上の信頼性とセキュリティの問題を引き起こしたためです:
    • NAT やモバイルネットワークがパスを頻繁に切り替えると、移行が繰り返し殺到する
    • 復旧したように見えてもメディアを配信しなくなった古いセッション
    • 長時間の無音期間の後に GAP のみの挙動が続く
    • 実際にローミング中のクライアントと、既存の session_id を主張する偽装パケットとの区別が曖昧
    • 誤ったタイミングでストリームの順序や再送状態をリセットしうる複雑な復旧状態
  • 現在のモデルは意図的にシンプルです: 現在の IP:port 上でのチャレンジによって到達可能性を証明し、セッションをそのエンドポイントにバインドし、エンドポイントが変わった場合は再接続します。
ツールをダウンロード