USTP

USTP steht für UDP Speedy Transmission Protocol.

USTP behält dasselbe authentifizierte Transportmodell bei, aber der Projektname lautet jetzt wieder einfach USTP.

Standardmäßig verwendet USTP AEAD für DATA.

Es unterstützt außerdem einen optional ausgehandelten cleartext + HMAC-Modus für DATA, bei dem die Nutzlastbytes auf der Leitung sichtbar sind, aber Manipulationen erkannt und abgelehnt werden.

USTP unterstützt jetzt einen optionalen Congestion-Controller namens USTP Congestion. Es ist weiterhin UDP-first, kann aber optional langsamer werden und wieder beschleunigen, wenn der Pfad beginnt, Congestion-Signale zu zeigen.

Status: Beta

USTP ist nicht länger nur ein Proof of Concept. Es befindet sich derzeit in der Beta-Phase.

USTP kann für viele Arten von Anwendungen und Transporten verwendet werden.

Dieses Repository konzentriert sich jedoch speziell auf Streaming über USTP.

Neuigkeiten

• 02/08/2026: USTP-Secure heißt jetzt wieder USTP.
  • USTP-Secure war ein alter Projektname und passt nicht mehr gut zum Projekt.
  • Der kürzere Name USTP wird jetzt wieder bevorzugt.
  • Der vollständige Name lautet jetzt UDP Speedy Transmission Protocol, ohne Secure im Titel.
• 2026-07-18: USTP/2 Beta wurde aus dem aktuellen Tree entfernt.
  • Das reale Verhalten war unter Paketverlust weniger stabil als USTP/1.1.
  • Der aktuelle stabile Transportpfad ist ausschließlich USTP/1.1.
  • Der Transport-Handshake verwendet jetzt Klartext-ASCII-Records.

Build-Hinweis

• Erstellt mit Codex unter Verwendung von GPT-5.4 (Low).
• Verifiziert ohne Einfrieren bei --loss 33.
• Testpfad: Brazil -> Canada mit etwa 140ms RTT.

Sicherheitsmodell

• Der Transport bleibt UDP (kein TCP-Tunnel)
• AEAD-Verschlüsselungsverfahren:
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• Standard-AEAD-Verschlüsselungsverfahren: chacha20
• Der Standard-DATA-Schutzmodus ist AEAD.
• Der optionale DATA-Schutzmodus ist Klartext + HMAC pro Paket.
• Im Klartextmodus werden die Nutzlastbytes nicht verschlüsselt, aber Änderungen werden erkannt und ungültige Pakete verworfen.
• Transport-Kontrollpakete (HELLO, ACK, RETRANSMIT_REQUEST, CLOSE) bleiben absichtlich im Klartext.
• Kontrollpakete werden als ASCII-Transport-Records serialisiert.
• ACK und NACK/RETRANSMIT_REQUEST bleiben im Klartext, werden aber mit einem sitzungsspezifischen HMAC-Tag authentifiziert.
• Dies verhindert, dass gefälschte Off-Path-ACK/NACK-Kontrollpakete ACK-Angriffe oder Retransmission-DoS erzwingen, nachdem die sichere Sitzung aufgebaut wurde.
• DATA-Pakete verwenden ein binäres Frame-Format namens UPACK (UPAK auf der Leitung).
• Es wird kein statischer PSK verwendet.
• Jeder Client führt beim Beitritt einen X25519-Schlüsselaustausch durch.
• Jeder Client erhält einen separaten AEAD-Sitzungsschlüssel.
• Server unterstützen mehrere Clients.
• Der Server validiert den Client mit einem Challenge-Roundtrip auf der Quell-IP:port.
• Wenn --cipher auf dem Server gesetzt ist, verwendet der Server genau dieses Verschlüsselungsverfahren.
• Wenn --cipher weggelassen oder auf auto gesetzt ist, verwendet der Server das vom Client angeforderte Verschlüsselungsverfahren.
• Clients lehnen unerwartete Verschlüsselungsaushandlung ab.
• Der DATA-Schutzmodus wird getrennt von der Wahl des Verschlüsselungsverfahrens ausgehandelt:
  • Server: --cleartext auto|on|off
  • Client: --cleartext on|off
  • Server-Standard: auto
  • Client-Standard: off
• Bei Server auto folgt der Server der Client-Anfrage.
• Bei Server on erzwingt der Server Klartext + HMAC.
• Bei Server off erzwingt der Server AEAD.
• TOFU (Trust On First Use) ist auf dem Client aktiviert, um unerwartete Änderungen des Server-Schlüssels nach der ersten Verbindung zu erkennen.
• Der Server speichert standardmäßig einen persistenten X25519-Hostschlüssel in ~/.ustps_host_key, damit TOFU über Wiederverbindungen und Neustarts hinweg stabil bleibt.
• Ein normaler Server-Neustart ändert den Hostschlüssel nicht.
• Verwenden Sie --regen-key auf dem Server nur, wenn Sie diesen Hostschlüssel absichtlich rotieren möchten.

Paket-Magic-Werte

• ACK:, NACK:, HELLO: und CLOSE: sind die Klartext-Präfixe der Steuerungsdatensätze.
• USS1 bedeutet UDP Speedy Secure, Version 1.
• USC1 bedeutet UDP Speedy Clear, Version 1.
• UPAK ist der binäre UPACK-DATA-Frame-Marker.
• In USTP ist die Klartext-Steuerung menschenlesbares ASCII wie ACK: 10, NACK: 42, HELLO: ... und CLOSE:.
• In USTP identifiziert UPAK binäre DATA-Pakete nach der Entschlüsselung.
• In USTP ist USS1 das äußere sichere AEAD-Umschlagformat.
• In USTP ist USC1 das äußere Klartext+HMAC-DATA-Umschlagformat.
• Auf der Leitung sieht man also normalerweise:
  • USS1... für AEAD-geschützte DATA
  • USC1... für Klartext+HMAC-DATA
  • lesbare Steuerungszeilen für die Transportsteuerung

Transportmodell

• USTP kann mit optionalem USTP Congestion laufen, das während des Handshakes ausgehandelt wird.
• Pakete tragen sowohl eine Transport-seq als auch eine anwendungsseitige stream_pos.
• seq wird für ACK, Verlusterkennung, Neuübertragung und RTT-Messung verwendet.
• stream_pos teilt der Anwendung mit, wohin die Nutzlast im logischen Bytestrom gehört.
• In der aktuellen Implementierung ist seq ein 32-Bit-Zähler, der für jede neue Sitzung bei 1 beginnt.
• In der aktuellen Implementierung ist stream_pos ein 64-Bit-Byte-Zähler, der für jeden neuen logischen Stream bei 0 beginnt.
• Der Empfänger akzeptiert Pakete sofort, anstatt die Zustellung hinter einem fehlenden Paket zu blockieren.

Handshake- und Sitzungsmodell

• Der Client beginnt mit einem Klartext-Transport-HELLO, das seinen X25519-Public-Key, die angeforderte Chiffre, den angeforderten Congestion-Control-Modus (on oder off) und den angeforderten DATA-Schutzmodus (cleartext on|off) überträgt.
• Der Server sendet nicht sofort Medien. Er sendet zuerst eine Klartext-Challenge mit:
  • einem zufälligen Retry-Token
  • einer generierten Base64-session_id
  • der ausgewählten Chiffre
  • dem ausgehandelten Congestion-Control-Modus
  • dem ausgehandelten DATA-Schutzmodus
  • dem Server-Public-Key
• Der Client muss mit exakt demselben Token und denselben Sitzungsmetadaten antworten.
• Erst nachdem dieser Token-Roundtrip erfolgreich war, erstellt der Server die Sitzung und beginnt mit dem Senden von DATA.
• Nach der Validierung ist die Sitzung an die Quell-IP:port gebunden, die die Challenge abgeschlossen hat.
• session_id wird weiterhin als Sitzungslabel verwendet, wird aber nicht von einer anderen IP:port akzeptiert.

Retry-Token

• USTP verwendet einen Klartext-Retry-Token-Schritt, bevor eine verschlüsselte Mediensitzung akzeptiert wird.
• Ablauf:
  • Client sendet HELLO
  • Server antwortet mit USTPS-CHALLENGE1 und überträgt token, session_id, ausgewählte Chiffre, ausgehandelten Congestion-Control-Modus, ausgehandelten DATA-Schutzmodus und Server-Public-Key
  • Client sendet dieses Token in USTPS-CHALLENGE-REPLY1 zurück
  • erst dann erstellt der Server die Sitzung und sendet USTPS-SESSION1
• Zweck:
  • nachweisen, dass der Absender an dieser Quell-IP:port tatsächlich dort Pakete empfangen kann
  • vermeiden, verschlüsselte Medien sofort an eine unvalidierte Quelladresse zu senden
  • die endgültige Sitzungserstellung an den Endpunkt binden, der den Roundtrip abgeschlossen hat
• Das Retry-Token ist nicht der Sitzungsschlüssel.
• Es ist nur ein Erreichbarkeitsnachweis und ein Handshake-Gate, bevor die eigentliche USTP-Sitzung erstellt wird.
• Es wird außerdem nicht als Nonce verwendet, nicht für sich allein als ACK/NACK-MAC-Schlüssel verwendet und nicht als Paketnutzlast-Zustand wiederverwendet.