Impostazione di un proxy SSL trasparente

Ho un box Linux impostato con 2 schede di rete per ispezionare il traffico che passa attraverso la porta 80. Una scheda viene utilizzata per uscire su Internet, l'altra è collegata a uno switch di rete. Il punto è poter ispezionare tutto il traffico HTTP e HTTPS sui dispositivi collegati a tale switch per scopi di debug.

Ho scritto le seguenti regole per iptables:

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Il 192.168.2.1:1337, ho un proxy http trasparente che utilizza Charles ( http://www.charlesproxy.com/ ) per la registrazione.

Va tutto bene per la porta 80, ma quando aggiungo regole simili per la porta 443 (SSL) che punta alla porta 1337, ricevo un errore sul messaggio non valido tramite Charles.

Ho usato il proxy SSL sullo stesso computer prima con Charles ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ), ma per qualche motivo non ho avuto successo nel farlo in modo trasparente. Alcune risorse che ho cercato su Google dicono che non è possibile - sono disposto ad accettarlo come risposta se qualcuno può spiegare il perché.

Come nota, ho pieno accesso alla configurazione descritta, compresi tutti i client collegati alla sottorete, quindi posso accettare certificati autofirmati da Charles. La soluzione non deve essere specifica per Charles poiché, in teoria, qualsiasi proxy trasparente lo farà.

Grazie!

Modifica: dopo averci giocato un po ', sono stato in grado di farlo funzionare per un host specifico. Quando modifico il mio iptables nel modo seguente (e apro 1338 in Charles per proxy inverso):

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Sono in grado di ottenere una risposta, ma senza host di destinazione. Nel proxy inverso, se ho appena specificato che tutto dal 1338 va a un host specifico che volevo colpire, esegue correttamente la stretta di mano e posso attivare il proxy SSL per ispezionare la comunicazione.

L'impostazione è tutt'altro che ideale perché non voglio supporre che tutto dal 1338 vada a quell'host - hai idea del perché l'host di destinazione è stato rimosso?

Grazie ancora

I problemi che riscontri sono gli stessi che impediscono l'uso di più certificati su un singolo indirizzo / porta IP (senza utilizzare l'indicazione del nome del server) .

In semplice HTTP, il proxy trasparente può dire a quale host il client vuole connettersi guardando Hostnell'intestazione.

Quando il proxy trasparente HTTPS MITM riceve la richiesta, non può sapere in primo luogo quale nome host richiedeva il client. (Non sono nemmeno sicuro che possa ottenere l'indirizzo IP con queste regole, che potrebbe almeno avergli permesso di fare un'ipotesi usando una ricerca DNS inversa, anche se è improbabile che funzioni nel caso generale.)

• Per ottenere il nome host previsto, il proxy MITM dovrebbe leggere l' Hostintestazione nel messaggio HTTP, che può verificarsi solo dopo una stretta di mano corretta.
• Per avere una stretta di mano corretta, il proxy MITM deve generare un certificato spoof corrispondente al nome host previsto.

Di conseguenza, il proxy MITM non può sapere quale certificato generare prima dell'handshake.

Questo può funzionare con un proxy MITM non trasparente, perché si otterrebbe almeno il nome host previsto tramite il CONNECTmetodo HTTP .

Solo alcune informazioni di base su questo argomento.

Ci sono solo alcuni dispositivi che conosco che possono eseguire con successo questa azione. Tuttavia, non sono realmente disponibili al pubblico comune. Io stesso sto usando un Fortinet Fortigate con SSL Offloading.

Ciò che fondamentalmente fa è; intercetta la connessione SSL effettuata all'host e decodifica la connessione nell'hardware, quindi controlla dove vuoi andare e prende una decisione di firewall in base a tali informazioni.

Successivamente imposta la propria connessione a quell'host per recuperare i dati e firmare nuovamente la richiesta originale al client utilizzando una CA fornita dall'utente. Per farlo funzionare senza problemi, è necessario disporre della CA nella CA radice attendibile sul client.

Questo tipo di configurazioni vengono utilizzate nelle organizzazioni per applicare le politiche aziendali relative all'utilizzo di Internet. Poiché l'utilizzo di Active Directory è facile installare la CA aziendale nei client, questo non costituisce un problema per le organizzazioni di grandi dimensioni.

Questo è l'UNICO modo in cui puoi farlo senza creare un proxy manuale, poiché il traffico SSL è crittografato. Fondamentalmente è un MITM, quindi è importante che siano coperti tutti i problemi legali.

Ci sono alcuni altri suggerimenti su questa altra domanda che potresti aver visto: miti e fatti del proxy SSL trasparenti . E c'è questo link che spiega come configurare Squid esattamente per diventare un proxy SSL trasparente. Non è quello che stai cercando, ma potrebbe almeno darti un'idea di cosa potrebbe andare storto.

Le regole di iptables sembrano a posto, ma non ho idea se il software proxy che stai usando sia in grado di fare quello che stai cercando di fare. La documentazione afferma certamente che questo è il caso.

Per aggiungere alla soluzione di Bruno, ho studiato un po 'e volevo condividere come ho ottenuto un'altra soluzione rapida tutt'altro che ideale.

Dopo aver impostato questi iptables, posso mettere un proxy inverso sulla porta 1338 e farlo inoltrare a localhost sulla porta 1337. Poiché la porta 1337 è un proxy http trasparente e i dati sono stati decifrati, prenderà l'intestazione host e ne farà la destinazione ospite.

Il principale svantaggio è che ho essenzialmente convertito una connessione https in http - che non funziona sempre con tutti i server (per non parlare del buco di sicurezza che sto esponendo da quello).

Stavo lavorando entro i limiti del mio software. Credo che una soluzione più pulita secondo Bruno sarebbe quella di ipotizzare che tutto il traffico proveniente dal 1338 debba essere decifrato. Dopo la decrittografia, ispezionare l'host di destinazione e quindi inoltrare la richiesta tramite SSL.