Potrebbe essere più semplice vederlo a tappe. Innanzitutto, in un mondo intero-HTTP (senza alcun tipo di SSL), una richiesta HTTP è una raccolta di intestazioni, che indica l'URL di destinazione e inviata tramite una connessione TCP (di solito sulla porta 80). Le intestazioni delle richieste iniziano con un "verbo" che di solito è GET o POST.
Quando c'è un proxy, la richiesta viene inviata al proxy; il proxy quindi apre la connessione al server di destinazione (o un altro proxy) e inoltra la richiesta su quella nuova connessione. La risposta segue lo stesso percorso, al contrario.
Ora entra in SSL. SSL è accoppiato con HTTP nel modo seguente: una volta stabilita la connessione TCP, viene eseguito un handshake SSL, stabilendo un tunnel crittografato tra client e server. La richiesta HTTP verrà inviata all'interno di questo tunnel.
Quando c'è un proxy, un client che desidera parlare con un server alimentato da SSL invierà una richiesta CONNECT. La richiesta identifica il nome e la porta del server di destinazione. Il proxy quindi si connette a quel server (TCP) e inoltra i byte avanti e indietro. L'handshake SSL si verifica tra il client e il server; il proxy viene mantenuto "all'esterno". Il proxy (e gli intercettatori sulla linea tra client e proxy e tra proxy e server) possono ancora vedere il messaggio di handshake e quindi sapere quale server viene contattato (in particolare tramite Server Name Indication , e anche il certificato inviato dal server).
Accade così che il proxy stesso possa anche essere un server SSL. In tal caso, le comunicazioni tra il client e il proxy saranno incapsulate in un tunnel SSL. Quando la connessione client-proxy è protetta da SSL, gli intercettatori sulla linea tra client e proxy possono sapere che il client sta parlando con il proxy, ma non possono vedere le richieste e le risposte. In particolare, non possono conoscere l'identità del server di destinazione finale.
I due SSL non sono correlati. Ciò implica una notevole confusione, perché quando le persone dicono "proxy HTTPS", possono significare due cose diverse:
- un proxy che conosce il verbo "CONNECT" ed è in grado di inoltrare le connessioni a un server di destinazione definitivo basato su SSL;
- un proxy che è a sua volta un server SSL e si impegnerà in SSL con il client, per proteggere le richieste e le risposte quando transitano tra client e proxy.
Le due caratteristiche sono ortogonali l'una con l'altra, il che significa che puoi ottenere l'una, l'altra o entrambe. Se hai entrambi, allora il client gestisce in realtà due connessioni SSL, una nidificata nell'altra.
Se vuoi sconfiggere gli intercettatori sulla linea tra client e proxy e l'obiettivo degli attaccanti è indovinare l'identità dei siti con cui stai parlando, allora hai bisogno di un proxy alimentato da SSL, cioè uno che supporti SSL da solo; e vorrete anche un proxy che supporti CONNECT, in modo che possiate esplorare sia il sito Web HTTP che HTTPS sotto la protezione del vostro proxy alimentato da SSL.
Poiché un determinato proxy può o non può supportare un protocollo specifico (almeno concettualmente, un proxy può rifiutarsi di comprendere una richiesta "CONNECT"), i browser Web possono essere configurati per utilizzare proxy diversi in base al tipo di protocollo che desiderano usare. Nel tuo caso, questo aggiunge solo confusione.
Un'alternativa è usare un proxy SOCKS. È facile da configurare con SSH . Con un proxy SOCKS basato su SSH, tutte le comunicazioni provenienti dal browser passeranno attraverso un tunnel SSH tra il computer client e il server proxy.