Proxy HTTP e HTTPS

Un proxy HTTP accetta richieste web dal browser o dall’applicazione e si connette alla destinazione per tuo conto. Può trasportare traffico HTTP ordinario e, con il supporto del metodo CONNECT, traffico HTTPS cifrato. Un proxy HTTPS aggiunge la cifratura alla connessione tra l’applicazione e il proxy stesso.

Sono due scelte separate: come l’applicazione raggiunge il proxy e come comunica con il sito web attraverso quel proxy. Comprenderle entrambe aiuta a selezionare le impostazioni di connessione corrette. La scelta più generale tra protocolli proxy è trattata in Proxy SOCKS e HTTP.

Che cosa fa un proxy HTTP con una richiesta web

Supponiamo che uno script di monitoraggio richieda http://example.com/catalog. Invece di aprire una connessione al sito, si connette al proxy configurato. Con HTTP/1.1, invia nella richiesta l’URL completo della destinazione, così il proxy sa quale server e pagina contattare. Il proxy inoltra la richiesta e restituisce allo script la risposta del sito.

In questa modalità, il proxy elabora messaggi HTTP. Può leggere il metodo, come GET o POST, l’indirizzo richiesto, le intestazioni e gli eventuali dati inviati. Un programma configurato per questi scopi può applicare regole di accesso, registrare richieste o memorizzare nella cache le risposte idonee. La cache è una funzione opzionale regolata dalle norme di memorizzazione della risposta; acquistare accesso a un proxy HTTP non significa che ogni pagina verrà salvata nella cache.

Il sito riceve la connessione di rete dall’IP di uscita del proxy. Il termine HTTP non dice da dove provenga quell’IP o per quanto tempo resti assegnato. Lo stesso protocollo di connessione può essere offerto con indirizzi datacenter, ISP, residenziali o mobili, usando IP fissi o un pool a rotazione.

Come un proxy HTTP apre un sito HTTPS

Un sito HTTPS usa TLS per proteggere lo scambio tra l’applicazione e il sito. Per trasportare quello scambio, un proxy HTTP crea prima un tunnel. Per una richiesta a https://example.com/catalog, la sequenza è:

1. L’applicazione si connette al proxy e gli chiede di aprire un tunnel verso example.com:443 usando il metodo CONNECT. La richiesta specifica host e porta della destinazione, senza il percorso della pagina.
2. Il proxy controlla che l’accesso e la destinazione richiesta siano consentiti, compresa l’eventuale autenticazione proxy necessaria. Apre una connessione alla destinazione e conferma che il tunnel è pronto.
3. L’applicazione esegue un handshake TLS con il sito attraverso il tunnel e controlla il certificato del sito.
4. L’applicazione invia la richiesta web all’interno di quella connessione TLS. Il proxy inoltra i byte cifrati in entrambe le direzioni.

Il proxy non deve leggere la pagina per consegnarla. L’applicazione e il sito restano gli estremi della connessione TLS del sito. CONNECT fornisce il tunnel; TLS fornisce la cifratura e protegge lo scambio da modifiche non rilevate.

Ecco perché un proxy HTTP può aprire un sito HTTPS anche quando l’indirizzo del proxy inizia con http://. La protezione HTTPS del sito opera all’interno del tunnel. Non dipende dalla presenza di TLS tra applicazione e proxy.

Che cosa aggiunge un proxy HTTPS

Con un proxy HTTPS, l’applicazione stabilisce prima TLS con il proxy e ne verifica il certificato. Poi invia le richieste HTTP, oppure la richiesta CONNECT per un tunnel, all’interno di quella connessione protetta. Un osservatore della rete tra applicazione e proxy non può leggere tali richieste.

Per una destinazione HTTPS, l’applicazione mantiene due connessioni TLS separate: una con il proxy e una con il sito attraverso il tunnel. Il proxy rimuove la protezione esterna indirizzata a sé, ma i dati del sito all’interno restano cifrati. Inoltra quei byte al sito, che può decifrarli. Per una destinazione HTTP non esiste una connessione TLS interna: è protetta soltanto la connessione al proxy.

Questo confronto descrive il normale inoltro proxy con i controlli dei certificati attivi, senza ispezione HTTPS o una VPN separata. Cifrare la connessione a un proxy non trasforma un sito HTTP in HTTPS.

Che cosa possono vedere il proxy e il sito

Per una destinazione HTTPS, un proxy di inoltro non può leggere il percorso della pagina, i parametri della query, i cookie, i dati dei moduli o i contenuti restituiti all’interno della connessione TLS. Conosce comunque l’IP del client che si è connesso, l’host e la porta di destinazione richiesti in CONNECT, nonché tempi e volume del traffico. TLS fino al proxy nasconde CONNECT agli osservatori su quella parte della rete, ma non al proxy che deve eseguirlo.

Le credenziali proxy vengono inviate separatamente dall’accesso al sito. L’autenticazione proxy Basic codifica nome utente e password con Base64, che può essere decodificato senza una chiave segreta. Su una normale connessione proxy HTTP, questo non li protegge da un osservatore della rete. La connessione HTTPS del sito inizia all’interno del tunnel e non copre il precedente accesso al proxy. TLS fino al proxy protegge quell’accesso durante il transito.

All’altro estremo, il sito riceve traffico dall’IP di uscita e legge le richieste indirizzate a sé. Può riconoscere un account, un cookie di sessione o altre informazioni inviate dall’applicazione. Scegliere un proxy HTTPS non elimina questi identificatori né migliora automaticamente l’accettazione dell’IP di uscita da parte del sito.

L’ispezione HTTPS è una configurazione diversa, usata in alcune reti gestite e negli strumenti di debug. L’applicazione si fida di un’autorità di certificazione controllata dal proxy di ispezione, che può quindi leggere il traffico mantenendo connessioni TLS separate sui due lati. Il normale inoltro CONNECT non richiede l’installazione di un certificato simile. La fiducia nel certificato server del proxy HTTPS è separata dal permesso di impersonare i siti web.

Come leggere le impostazioni di connessione

Un’impostazione proxy richiede un indirizzo, una porta, un protocollo di connessione e l’eventuale autenticazione necessaria. Il protocollo nell’URL del proxy si applica al proxy. Il protocollo nell’URL di destinazione si applica al sito.

Questi comandi curl richiedono lo stesso sito HTTPS attraverso due connessioni proxy diverse. Sostituisci hostname e porta del proxy con i valori forniti per il metodo di connessione scelto:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

Il primo comando si connette al proxy tramite HTTP, poi crea CONNECT e TLS fino al sito. Il secondo crea prima TLS fino al proxy HTTPS, poi trasporta al suo interno la connessione TLS separata del sito. In entrambi i casi, fornisci anche l’autenticazione richiesta dal servizio proxy.

Cambiare semplicemente http:// in https:// non trasforma una porta esclusivamente HTTP in un endpoint TLS. Se il servizio fornisce un hostname per l’accesso HTTPS, usa quello: sostituirlo con un IP può causare una mancata corrispondenza del nome nel certificato.

Le etichette nelle applicazioni richiedono la stessa attenzione. Un campo chiamato “proxy HTTPS” può selezionare il proxy per i siti HTTPS continuando a connettersi a esso tramite HTTP non cifrato. In curl, anche la variabile HTTPS_PROXY seleziona un proxy per destinazioni HTTPS; il suo valore può correttamente iniziare con http://. L’etichetta indica quali richieste usano l’impostazione, mentre lo schema del proxy indica come viene stabilita la connessione.

DNS e traffico che attraversa il proxy

Quando un client HTTP fornisce un hostname di destinazione, il proxy ne cerca normalmente l’IP e vi si connette. Il client esegue una ricerca separata se necessita dell’hostname del proxy stesso per raggiungerlo. Un browser può anche inviare richieste DNS per la previsione o altre funzioni. Sono ricerche separate; impostare un proxy web non instrada ogni richiesta DNS attraverso di esso.

L’impostazione si applica al traffico effettivamente inviato dall’applicazione al proxy. Un altro programma può continuare a connettersi direttamente e un elenco di eccezioni può evitare il proxy per determinati siti. Per esempio, instradare uno script API tramite un proxy non cambia il percorso usato da un browser non correlato. Controlla l’indirizzo di uscita dall’applicazione e dalla configurazione che eseguiranno l’attività.

HTTP/2 fino al sito e HTTP/2 fino al proxy

HTTP/2 permette a più scambi di condividere una connessione tramite flussi separati. Con un proxy, conta quale connessione lo supporta. Un’applicazione può negoziare HTTP/2 con un sito all’interno di un tunnel creato con HTTP/1.1 CONNECT. Il proxy inoltra i byte cifrati e non deve comprendere i messaggi HTTP/2 del sito.

HTTP/2 tra applicazione e proxy è una funzionalità separata. Ogni tunnel CONNECT usa un proprio flusso HTTP/2, quindi più tunnel possono condividere una connessione al proxy. Per esempio, i tunnel verso due siti diversi possono usare quella connessione mantenendo connessioni alle destinazioni e sessioni TLS dei siti separate. Questo riduce la necessità di connessioni client-proxy aggiuntive; non permette al proxy di leggere le richieste cifrate ai siti.

Entrambi i lati devono supportare la modalità scelta. Il solo HTTPS non specifica HTTP/2: un proxy HTTPS può usare HTTP/1.1. Le prestazioni dipendono anche da client, percorso di rete, carico del server e riutilizzo delle connessioni. Un’etichetta HTTP/2 non garantisce un aumento di velocità per ogni attività.

Un normale tunnel CONNECT può trasportare anche altri protocolli basati su TCP se applicazione e proxy lo consentono, sebbene le porte di destinazione possano essere limitate. Non inoltra UDP. HTTP/3 usa QUIC su UDP e non può quindi attraversare quel tunnel TCP allo stesso modo. L’inoltro UDP basato su HTTP usa meccanismi aggiuntivi, come CONNECT-UDP, e richiede implementazioni compatibili. Il solo supporto HTTPS o HTTP/2 non dimostra la presenza di tale funzionalità.

Quando è utile l’accesso proxy HTTP e HTTPS

Per navigazione e test di siti, un proxy HTTP con CONNECT offre un metodo di connessione sia alle destinazioni HTTP sia a quelle HTTPS. Un gruppo può usarlo per visualizzare un sito dalla rete del proxy, lasciando al browser la gestione di visualizzazione delle pagine, cookie e accessi ai siti.

Per crawler, client API e monitor programmati, un client HTTP può inviare richieste attraverso un IP di uscita scelto mantenendo invariati gli URL di destinazione. L’applicazione prepara comunque le richieste ed elabora le risposte. All’interno di un tunnel HTTPS, il proxy trasporta lo scambio senza dover analizzare ogni pagina o chiamata API.

Un proxy HTTPS protetto da TLS è utile quando anche la connessione al proxy necessita di protezione, compresi l’accesso al proxy e le richieste di destinazione. Conta quando quella connessione attraversa una rete che non controlli. Il client deve supportare TLS fino al proxy stesso; la sola capacità di aprire siti HTTPS non basta.

Interpretare gli errori di connessione

Un errore può verificarsi nel raggiungere il proxy, aprire il tunnel o comunicare con il sito. La fase rivela più del solo codice di errore.

Un tunnel completato e un handshake TLS riuscito mostrano che il percorso di connessione funziona. Non garantiscono che il sito accetti un determinato account, IP di uscita o richiesta. Una richiesta di accesso, un CAPTCHA o un limite di richieste possono quindi richiedere attenzione a livello di sito o applicazione anche quando il proxy funziona.