mitm-proxy-ja3-ja4

English | Русский

Un proxy MITM HTTP realizzato con Rust, tokio e btls.

Questo progetto è stato completamente riscritto per sfruttare btls (BoringSSL) per capacità avanzate di fingerprinting TLS. Il livello di fingerprinting TLS (JA3/JA4) è ora completamente falsificabile — cipher suite, curve, algoritmi di firma, ALPN, limite di dimensione dei record, compressione dei certificati, GREASE, permutazione/ordinamento delle estensioni, OCSP stapling, Certificate Transparency (SCT), session ticket, ALPS ed Encrypted Client Hello (ECH, risolto in tempo reale tramite DoH, con fallback a GREASE) sono tutti guidati da un profilo YAML. Anche il fingerprinting HTTP/2 (Akamai) e l'ordinamento/riscrittura degli header HTTP/1.1 sono completamente configurabili. Anche il fingerprinting TCP (L4) è attivo: i pacchetti SYN delle connessioni upstream vengono riscritti in NFQUEUE (TTL, dimensione della finestra, MSS, window scale, flag DF, timestamp, ordine esatto delle opzioni TCP, mark per dominio) con gestione automatica di iptables.

Configurazione della falsificazione del fingerprint TLS

TLS

Configurazione della falsificazione del fingerprint HTTP/2

HTTP/2

Configurazione della falsificazione del fingerprint TCP

TCP

Funzionalità (implementazione attuale)

• MITM (Man-in-the-Middle) — Intercettazione HTTPS trasparente. Utilizza rcgen per emettere e firmare dinamicamente i certificati al volo, memorizzandoli in cache tramite moka per le prestazioni.

• Integrazione con BoringSSL — Utilizza btls e tokio-btls per la gestione dell'handshake TLS e l'intercettazione MITM.

• Falsificazione del fingerprint TLS (JA3/JA4) — completa. La connessione TLS upstream è costruita interamente da un profilo YAML passato tramite -c / --config <path> (vedere config.yaml per il formato):

  • Cipher suite, in ordine rigorosamente definito dal chiamante.
  • Curve ellittiche.
  • Algoritmi di firma.
  • Negoziazione ALPN basata sul protocollo effettivamente selezionato dal server upstream.
  • Limite di dimensione dei record.
  • Compressione dei certificati (brotli, zlib, zstd) con reale supporto alla decompressione.
  • GREASE.
  • Ordine esatto delle estensioni TLS nel ClientHello, oppure permutazione casuale in stile Chrome.
  • Toggle per OCSP stapling, Certificate Transparency (SCT), session ticket e ALPS (Application-Layer Protocol Settings).
  • Encrypted Client Hello (ECH) — la configurazione ECH reale viene risolta in tempo reale tramite DoH (ricerca record HTTPS/SVCB) per ogni host upstream, utilizzando lo stesso profilo di fingerprint TLS/HTTP2 per la richiesta DoH stessa; ricade su ECH GREASE (o su nulla) quando non viene trovata alcuna configurazione, configurabile in modo indipendente — vedere TLS.md per i dettagli.

• Negoziazione ALPN con priorità all'upstream — Il proxy stabilisce e negozia il TLS con il server upstream prima di completare l'handshake TLS lato browser. L'ALPN selezionato dal server upstream viene quindi utilizzato per configurare l'acceptor TLS lato client, impedendo al browser di selezionare un protocollo che la connessione upstream non supporta.

• Falsificazione del fingerprint HTTP/2 (Akamai) — Fingerprinting HTTP/2 completamente configurabile tramite il profilo YAML:

  • Valori SETTINGS HTTP/2 e ordine esatto dei SETTINGS.
  • Aggiornamenti della finestra di controllo di flusso a livello di connessione.
  • ID di stream iniziale configurabile con calcolo automatico quando sono configurati frame di priorità.
  • Frame di priorità HTTP/2 e priorità degli header di richiesta.
  • Posizionamento configurabile di END_STREAM per richieste vuote.
  • Ordinamento degli pseudo-header.
  • Ordinamento degli header HTTP.
  • Sostituzione, aggiunta e rimozione degli header HTTP.
  • Inoltro in streaming dei body di richiesta e risposta senza bufferizzare il body completo.
  • Supporto ai trailer HTTP/2.

• Falsificazione degli header HTTP/1.1 — Ordine e contenuto degli header configurabili per le connessioni upstream HTTP/1.1 in chiaro (quando ALPN non negozia h2), rispecchiando la stessa semantica di override/rimozione utilizzata per HTTP/2.

• Falsificazione del fingerprint TCP (L4) — completa. Le connessioni upstream in uscita vengono fingerprintate a livello di pacchetto tramite NFQUEUE di Linux (src/tcp_fingerprint/):

  • Riscrittura SYN: TTL, dimensione della finestra, flag DF, valori MSS / window-scale, toggle del timestamp, ordine esatto delle opzioni TCP (o patching dei valori in-place quando non è impostato alcun ordine), con ricalcolo del checksum.

• Patching della coda dei flussi stabiliti solo per TTL/DF (hop limit IPv6 supportato); ogni pacchetto riceve un verdetto Accept per impostazione predefinita, così le code non si bloccano mai.

• Routing basato su SO_MARK verso profili TCP per dominio, gestione automatica di iptables (inserita in cima rispetto a strumenti come zapret/nfqws, deduplicata, rimossa allo spegnimento con Ctrl+C) con la sicurezza di --queue-bypass.

• Vedi TCP.md e il blocco tcp in config.yaml.

• Supporto proxy HTTP upstream — Può inoltrare le connessioni attraverso un proxy HTTP upstream tramite il metodo CONNECT.

• Routing dei profili per dominio — Passa -d / --domain <path> con una mappa di pattern di dominio verso overlay parziali di profilo (vedi domain.yaml). Ogni connessione viene associata tramite SNI (esatto → *.root → *.label.* → label.* → profilo base) e servita con le proprie impostazioni TCP/TLS/HTTP2/HTTP1/upstream, precompilate una sola volta all'avvio. È necessario specificare solo i campi che differiscono dal profilo base; tutto il resto viene ereditato.

• Asincrono — Basato su tokio per I/O asincrono non bloccante ad alte prestazioni.

Requisiti

• Rust (edition 2021)
• Linux (richiesto per le funzionalità NFQUEUE L4)
• Root o cap_net_admin,cap_net_raw=+eip (per SO_MARK, il bind NFQUEUE e iptables automatico; in assenza di ciò imposta "auto_iptables": false nel blocco tcp e applica manualmente le regole mangle — vedi TCP.md)
• Firefox con Multi-Account Containers (altamente consigliato per sfruttare più fingerprint contemporaneamente)

Logging

Il proxy utilizza tracing con filtraggio per modulo tramite RUST_LOG.

Esempi:

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

I tag supportati sono gli stessi nomi di modulo usati nel codice: TCP, HTTP, H1, H2, TLS, CA, ECH, CFG, IPT, NFQUEUE, Runtime.

Le righe di log includono un timestamp per impostazione predefinita, così le sessioni di debug sono più facili da correlare.

Installazione e utilizzo

1. Compilazione

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

2. Esecuzione

Tutte le impostazioni — porta, proxy upstream e percorsi dei file CA — risiedono nel file di configurazione YAML passato tramite -c / --config <path>. Non esistono flag CLI --port / --upstream.

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

Per eseguire senza un proxy upstream, impostare upstream_proxy: null.

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