HomeOpereInfo
ContattoBlog</>
it/blog/obscura/research/mitm-approaches/
✕

obscura/research/mitm-approaches

3 min di lettura

Panoramica

Obscura richiede un proxy MitM (Man-in-the-Middle) per intercettare e modificare il traffico HTTPS. Questo documento valuta le opzioni disponibili.

Approcci

Approccio 1: Libreria Go mitmproxy

Libreria: github.com/elazarl/goproxy

Pro:

  • Matura, ben testata
  • Gestisce automaticamente i tunnel CONNECT
  • Supporta la modifica delle risposte
  • MITM con generazione di certificati al volo

Contro:

  • Il supporto HTTP/2 è limitato
  • Albero di dipendenze ampio
  • Non progettato per proxy trasparente

Approccio 2: Proxy Rust Personalizzato con tokio + rustls

Pro:

  • Controllo completo dello stack TLS
  • Prestazioni (astrazioni a costo zero)
  • tokio-rustls per la terminazione TLS
  • Hyper per HTTP/1 e HTTP/2
  • Può integrare utls per lo spoofing del fingerprint TLS

Contro:

  • Maggiore sforzo di sviluppo
  • Deve gestire la generazione dei certificati manualmente
  • Richiede parsing a livello di frame HTTP/2

Approccio 3: Squid + Modifica Esterna

Pro:

  • Proxy testato sul campo
  • SSL Bump per MITM
  • ICAP/eCAP per modifica contenuti

Contro:

  • Configurazione complessa
  • Versioni EOL ancora in uso
  • Non progettato per iniezione JS
  • Immagine container pesante

Approccio 4: Envoy Proxy con Wasm Filter

Pro:

  • Alte prestazioni
  • Proxy L4/L7
  • Filtri WebAssembly (Wasm) per modifica
  • HTTP/2 e HTTP/3 nativi

Contro:

  • Configurazione complessa
  • Overhead di sviluppo filtri Wasm
  • Non progettato per iniezione JS lato client
  • Eccessivo per distribuzioni su piccola scala

Approccio 5: Intercettazione a Livello TCP Personalizzata

Intercettazione socket raw + terminazione TLS:

  1. Usa iptables TPROXY per reindirizzare il traffico
  2. Lettura socket TCP raw
  3. Handshake TLS manuale (tramite rustls/crypto/tls)
  4. Parsing HTTP/1.1 o HTTP/2
  5. Modifica header + iniezione JS
  6. Inoltro all'upstream

Pro:

  • Massimo controllo
  • Nessuna dipendenza da framework proxy
  • Può gestire tutti i casi limite

Contro:

  • Massimo sforzo di sviluppo
  • Deve implementare la gestione di HTTP/2 e HTTP/3
  • Deve gestire correttamente il connection pooling

Raccomandazione

Per Obscura, una implementazione Rust personalizzata (Approccio 2) è il miglior compromesso:

  • goproxy di Go manca di HTTP/2 e spoofing TLS
  • Rust offre controllo granulare su TLS (integrazione utls)
  • Le prestazioni sono importanti per un gateway di rete
  • Le garanzie di sicurezza di Rust riducono i bug del proxy

Generazione Certificati

Per il MITM, il proxy deve generare certificati TLS al volo:

  1. Un certificato CA viene generato al primo avvio
  2. Per ogni nuovo dominio, un certificato foglia viene firmato dalla CA
  3. Il client deve fidarsi del certificato CA
CA Obscura (chiave privata)
   *.example.com (foglia, generato alla prima richiesta)
   *.anotherexample.com (foglia, generato alla prima richiesta)

Archiviazione Certificati

/var/lib/obscura/certs/
 ca.pem          # Certificato CA (pubblico)
 ca-key.pem      # Chiave privata CA
 cache/          # Certificati foglia generati
    example.com.pem
    ...
 serial          # Contatore seriale certificati

Limitazioni

  • HPKP (HTTP Public Key Pinning): Ora deprecato in Chrome, ma alcuni siti lo usano ancora
  • HSTS preloading: I siti nell'elenco di precaricamento HSTS (es. google.com, stripe.com) rifiuteranno i certificati MITM. Devono essere intercettati prima a livello DNS/network.
  • Certificate Transparency: Alcuni siti richiedono log CT. Il proxy deve incorporare SCT.
  • HTTP/3 (QUIC): Funziona su UDP ed è crittografato end-to-end. Deve essere bloccato a livello di rete.

Conclusioni

  • Rust con tokio-rustls + hyper è lo stack proxy raccomandato
  • Lo spoofing del fingerprint TLS richiede l'integrazione utls
  • I siti con precaricamento HSTS devono essere gestiti a livello DNS/network
  • HTTP/3 deve essere bloccato (QUIC bypassa il proxy)
✕