mitm-proxy-ja3-ja4

English | Русский

Ein HTTP-MITM-Proxy, entwickelt mit Rust, tokio und btls.

Dieses Projekt wurde vollständig neu geschrieben, um btls (BoringSSL) für fortgeschrittene TLS-Fingerprinting-Fähigkeiten zu nutzen. Die TLS-Fingerprinting-Schicht (JA3/JA4) ist nun vollständig spoofbar — Cipher Suites, Kurven, Signaturalgorithmen, ALPN, Record-Size-Limit, Zertifikatskompression, GREASE, Extension-Permutation/-Reihenfolge, OCSP-Stapling, Certificate Transparency (SCT), Session Tickets, ALPS und Encrypted Client Hello (ECH, live über DoH aufgelöst, mit GREASE-Fallback) werden alle durch ein YAML-Profil gesteuert. HTTP/2-Fingerprinting (Akamai) sowie HTTP/1.1-Header-Reihenfolge/-Umschreibung sind ebenfalls vollständig konfigurierbar. Auch TCP-(L4-)Fingerprinting ist live: SYN-Pakete von Upstream-Verbindungen werden in NFQUEUE umgeschrieben (TTL, Fenstergröße, MSS, Window Scale, DF-Flag, Zeitstempel, exakte TCP-Option-Reihenfolge, Markierungen pro Domain) mit automatischer iptables-Verwaltung.

Konfiguration des TLS-Fingerprint-Spoofings

TLS

Konfiguration des HTTP/2-Fingerprint-Spoofings

HTTP/2

Konfiguration des TCP-Fingerprint-Spoofings

TCP

Funktionen (aktuelle Implementierung)

• MITM (Man-in-the-Middle) — Transparente HTTPS-Interception. Es verwendet rcgen, um Zertifikate dynamisch on-the-fly auszustellen und zu signieren, und cached sie über moka für bessere Performance.

• BoringSSL-Integration — Verwendet btls und tokio-btls für die TLS-Handshake-Verarbeitung und MITM-Interception.

• TLS-Fingerprint-Spoofing (JA3/JA4) — vollständig. Die Upstream-TLS-Verbindung wird vollständig aus einem YAML-Profil aufgebaut, das über -c / --config <path> übergeben wird (das Format ist in config.yaml beschrieben):

  • Cipher Suites, in strikt vom Aufrufer definierter Reihenfolge.
  • Elliptische Kurven.
  • Signaturalgorithmen.
  • ALPN-Aushandlung basierend auf dem tatsächlich vom Upstream-Server gewählten Protokoll.
  • Record-Size-Limit.
  • Zertifikatskompression (brotli, zlib, zstd) mit echter Dekompressionsunterstützung.
  • GREASE.
  • Exakte TLS-Extension-Reihenfolge im ClientHello oder Chrome-artige zufällige Permutation.
  • OCSP-Stapling, Certificate Transparency (SCT), Session Ticket und ALPS (Application-Layer Protocol Settings) als umschaltbare Optionen.
  • Encrypted Client Hello (ECH) — die echte ECH-Konfiguration wird live über DoH (HTTPS/SVCB-Record-Lookup) für jeden Upstream-Host aufgelöst, wobei dasselbe TLS/HTTP2-Fingerprint-Profil für die DoH-Anfrage selbst verwendet wird; fällt auf ECH GREASE (oder nichts) zurück, wenn keine Konfiguration gefunden wird, unabhängig konfigurierbar — Details siehe TLS.md.

• Upstream-First-ALPN-Aushandlung — Der Proxy baut die TLS-Verbindung zum Upstream-Server auf und handelt sie aus, bevor der browser-seitige TLS-Handshake abgeschlossen wird. Das vom Upstream-Server gewählte ALPN wird dann verwendet, um den clientseitigen TLS-Acceptor zu konfigurieren, wodurch verhindert wird, dass der Browser ein Protokoll wählt, das die Upstream-Verbindung nicht unterstützt.

• HTTP/2-Fingerprint-Spoofing (Akamai) — Vollständig konfigurierbares HTTP/2-Fingerprinting über das YAML-Profil:

  • HTTP/2-SETTINGS-Werte und exakte SETTINGS-Reihenfolge.
  • Flow-Control-Fenster-Updates auf Verbindungsebene.
  • Konfigurierbare initiale Stream-ID mit automatischer Berechnung, wenn Priority-Frames konfiguriert sind.
  • HTTP/2-Priority-Frames und Request-Header-Priorität.
  • Konfigurierbare END_STREAM-Platzierung für leere Requests.
  • Pseudo-Header-Reihenfolge.
  • HTTP-Header-Reihenfolge.
  • Ersetzen, Hinzufügen und Entfernen von HTTP-Headern.
  • Streaming-Weiterleitung von Request- und Response-Bodies ohne Pufferung des vollständigen Bodys.
  • Unterstützung für HTTP/2-Trailers.

• HTTP/1.1-Header-Spoofing — Konfigurierbare Header-Reihenfolge und -Inhalt für reine HTTP/1.1-Upstream-Verbindungen (wenn ALPN kein h2 aushandelt), mit denselben Override-/Removal-Semantiken wie bei HTTP/2.

• TCP-Fingerprint-Spoofing (L4) — vollständig. Ausgehende Upstream-Verbindungen werden auf Paketebene über Linux NFQUEUE gefingerprintet (src/tcp_fingerprint/):

  • SYN-Umschreibung: TTL, Fenstergröße, DF-Flag, MSS / Window-Scale-Werte, Timestamp-Umschaltung, exakte TCP-Optionen-Reihenfolge (oder In-Place-Wert-Patching, wenn keine Reihenfolge festgelegt ist), mit Neuberechnung der Prüfsumme.
  • Patching der Warteschlange etablierter Flows nur für TTL/DF (IPv6-Hop-Limit wird unterstützt); jedes Paket erhält standardmäßig ein Accept-Urteil, sodass Warteschlangen nie blockieren.
  • SO_MARK-basiertes Routing zu TCP-Profilen pro Domain, automatische iptables-Verwaltung (oben eingefügt über Tools wie zapret/nfqws, dedupliziert, bei Ctrl+C-Shutdown entfernt) mit --queue-bypass-Sicherheit.
  • Siehe TCP.md und den tcp-Block in config.yaml.

• Unterstützung für vorgelagerte HTTP-Proxys — Kann Verbindungen über einen vorgelagerten HTTP-Proxy mittels der CONNECT-Methode proxyen.

• Pro-Domain-Profil-Routing — Übergeben Sie -d / --domain <path> mit einer Zuordnung von Domain-Mustern zu partiellen Profil-Overlays (siehe domain.yaml). Jede Verbindung wird per SNI abgeglichen (exakt → *.root → *.label.* → label.* → Basisprofil) und mit ihren eigenen TCP/TLS/HTTP2/HTTP1/Upstream-Einstellungen bedient, die beim Start einmalig vorab erstellt werden. Es müssen nur die Felder angegeben werden, die vom Basisprofil abweichen; alles andere wird geerbt.

• Asynchron — Basiert auf tokio für hochperformante, nicht-blockierende asynchrone I/O.

Anforderungen

• Rust (Edition 2021)
• Linux (erforderlich für die NFQUEUE-L4-Funktionen)
• Root oder cap_net_admin,cap_net_raw=+eip (für SO_MARK, NFQUEUE-Bind und automatisches iptables; ohne dies setzen Sie "auto_iptables": false im tcp-Block und wenden die Mangle-Regeln manuell an — siehe TCP.md)
• Firefox mit Multi-Account Containers (sehr empfohlen, um mehrere Fingerprints gleichzeitig zu nutzen)

Protokollierung

Der Proxy verwendet tracing mit Filterung pro Modul über RUST_LOG.

Beispiele:

RUST_LOG='H2=error' cargo run --release -- -c profile.yaml
RUST_LOG='TCP=debug,H2=error,TLS=warn' cargo run --release -- -c profile.yaml
RUST_LOG='CA=info,TLS=warn,H2=error' cargo run --release -- -c profile.yaml

Unterstützte Tags sind dieselben Modulnamen, die im Code verwendet werden: TCP, HTTP, H1, H2, TLS, CA, ECH, CFG, IPT, NFQUEUE, Runtime.

Logzeilen enthalten standardmäßig einen Zeitstempel, sodass Debugging-Sitzungen leichter korreliert werden können.

Installation & Verwendung

1. Build

git clone https://github.com/3Radiance/mitm-proxy-ja3-ja4.git
cd mitm-proxy-ja3-ja4
cargo build --release

2. Ausführen

Alle Einstellungen – Port, Upstream-Proxy und CA-Dateipfade – befinden sich in der YAML-Konfiguration, die über -c / --config <path> übergeben wird. Es gibt keine --port / --upstream CLI-Flags.

config: 
  port: 9090
  upstream_proxy: "127.0.0.1:10808"
  cert: "/path/to/ca.crt"
  key: "/path/to/ca.key"

Um ohne einen vorgeschalteten Proxy zu laufen, setzen Sie upstream_proxy: null.

cargo run --release -- --config profile.yaml
# or
cargo run --release -- -c profile.yaml