Proxy SOCKS5 e SOCKS4

Un proxy SOCKS permette a un’applicazione di chiedere a un server intermediario di connettersi a una destinazione per suo conto. Il proxy apre la connessione richiesta e passa i dati in entrambe le direzioni. L’applicazione continua a usare il proprio protocollo, quindi questo funziona per richieste web, client API, trasferimenti di file e altri programmi con supporto SOCKS.

Per una nuova configurazione, SOCKS5 offre di solito le opzioni più utili: più formati di indirizzo, una scelta di metodi di autenticazione e supporto UDP. SOCKS4 resta utile per i programmi che richiedono la versione precedente. La scelta più generale tra questi protocolli e i proxy HTTP è trattata in Proxy SOCKS e HTTP.

Come un’applicazione si connette tramite SOCKS

Considera un’applicazione che apre https://example.com/ tramite un proxy SOCKS5. Prima raggiunge il proxy, gli chiede di aprire una connessione al sito e soltanto dopo scambia i dati del sito. Il processo ha quattro fasi:

1. L’applicazione si connette tramite TCP all’hostname o all’IP del proxy e alla sua porta di ascolto.
2. L’applicazione e il proxy selezionano un metodo di accesso. Se richiede credenziali, l’applicazione le fornisce e il proxy le controlla.
3. L’applicazione invia una richiesta SOCKS CONNECT con indirizzo e porta di destinazione. Il proxy controlla le regole di accesso, tenta la connessione alla destinazione e ne comunica il risultato.
4. Dopo una risposta positiva, l’applicazione comunica con la destinazione attraverso il proxy. Per un sito HTTPS, stabilisce TLS con il sito e ne verifica il certificato prima di inviare la richiesta web.

I due numeri di porta appartengono a server diversi. Un proxy di esempio potrebbe ascoltare su proxy.example:1080, mentre il sito viene raggiunto su example.com:443. La porta 1080 è convenzionale per SOCKS, ma un servizio può usarne un’altra. Usa la porta di ascolto assegnata al tuo proxy; non sostituisce la porta della destinazione.

Durante il normale inoltro TCP, SOCKS passa il flusso di byte dell’applicazione senza dover interpretare ogni richiesta HTTP o comando di file. L’applicazione continua a usare il proprio protocollo con la destinazione. Per questo lo stesso meccanismo di connessione SOCKS può servire client web e altri tipi di programmi.

CONNECT è un comando di SOCKS, con un proprio formato dei messaggi; è diverso dal metodo HTTP CONNECT. SOCKS definisce anche BIND per le applicazioni che necessitano di una connessione di ritorno da un server attraverso il proxy, come può avvenire con FTP attivo. BIND richiede un supporto separato e non viene usato per una normale richiesta a un sito o a un’API.

Che cosa cambia tra SOCKS4, SOCKS4a e SOCKS5

SOCKS4 apre connessioni TCP a indirizzi IPv4. SOCKS4a aggiunge la possibilità di inviare un hostname, così il proxy può trovarne l’IP tramite DNS. SOCKS5 aggiunge una scelta di metodi di autenticazione, accetta indirizzi IPv4, indirizzi IPv6 e hostname e definisce l’inoltro UDP.

Sono capacità del protocollo. Il client e il servizio proxy devono implementare la funzione specifica che intendi usare. Per esempio, un servizio SOCKS5 può gestire connessioni TCP senza offrire un inoltro UDP utilizzabile.

SOCKS5 può includere una destinazione IPv6 nella richiesta, ma il proxy deve anche poter raggiungere quel server IPv6. Le due connessioni possono usare versioni IP diverse: l’applicazione può raggiungere il proxy tramite IPv4, mentre il proxy si connette alla destinazione tramite IPv6.

SOCKS4a è un’estensione di SOCKS4, non un altro nome di ogni connessione SOCKS4. Se un vecchio client invia soltanto indirizzi IPv4, selezionare SOCKS4 non gli fornisce DNS remoto. SOCKS4a richiede supporto a entrambi gli estremi. SOCKS5 è normalmente la scelta più semplice quando entrambi lo supportano; selezionare SOCKS4 non migliora di per sé la reputazione o la velocità dell’IP di uscita.

Chi risolve il nome della destinazione

Prima che una connessione possa raggiungere un server indicato per nome, il nome deve essere tradotto in un indirizzo IP. SOCKS5 può accettare il risultato di quella ricerca oppure il nome stesso. L’impostazione DNS del client determina che cosa invia.

Con DNS locale, l’applicazione interroga il resolver configurato per reports.example. Supponiamo che la risposta sia 203.0.113.27: l’applicazione richiede poi una connessione SOCKS a 203.0.113.27:443. La ricerca è già avvenuta dal lato client, anche se la successiva connessione al sito attraversa il proxy.

Con DNS dal lato proxy, l’applicazione invia reports.example:443 senza prima cercare localmente quella destinazione. Il proxy ne ottiene l’IP tramite DNS e apre la connessione richiesta. L’hostname raggiunge il proxy come parte della richiesta SOCKS.

Questo può aiutare quando il client non riesce a risolvere un nome che il proxy può risolvere. Alcuni servizi restituiscono indirizzi diversi in base al resolver DNS, quindi spostare la ricerca può cambiare il server che riceve la connessione. Non imposta il paese di uscita del proxy e non garantisce che il sito accetti la richiesta.

In curl, i due comandi seguenti scelgono le due modalità DNS:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// fa risolvere a curl il nome del sito localmente; socks5h:// lo passa al proxy. Entrambi usano SOCKS5. La h indica la risoluzione dell’hostname da parte del proxy nella sintassi URL di questo client. Non trasforma SOCKS5 in HTTPS e non aggiunge cifratura. Altre applicazioni possono usare una casella di selezione o scegliere automaticamente DNS remoto. Sostituisci hostname e porta del proxy di esempio con i dati del tuo servizio e fornisci l’autenticazione richiesta.

Passare un nome di dominio in una richiesta TCP SOCKS5 non richiede il supporto dell’inoltro UDP. Il proxy esegue la ricerca usando la propria configurazione DNS. È diverso dal chiedere a SOCKS5 di trasportare i pacchetti UDP di un client.

Se un client è configurato per lasciare al proxy il DNS della destinazione ma esegue la ricerca localmente, espone il nome richiesto al di fuori del percorso previsto. È una fuga di richieste DNS. Il DNS cifrato protegge lo scambio con il resolver, ma quel resolver riceve comunque il nome. Cercare l’hostname del proxy stesso è un’attività separata e le altre applicazioni mantengono il proprio comportamento DNS. Il DNS remoto in un programma non sposta ogni ricerca del dispositivo.

Autenticazione e cifratura

SOCKS5 permette al client di offrire i metodi di autenticazione supportati e al proxy di sceglierne uno. Nome utente e password sono un’opzione. Un’altra è una connessione senza scambio di accesso SOCKS, che un servizio può consentire dopo aver controllato l’IP di origine del client rispetto a un elenco di IP consentiti. Un endpoint senza campo password può quindi limitare comunque l’accesso.

Il mancato accordo su un metodo è diverso da una password rifiutata: nel primo caso, lo scambio della password non è avvenuto. Un client che non supporta nome utente/password non può usare un endpoint SOCKS5 accessibile solo con password semplicemente perché dispone di un’impostazione SOCKS5. SOCKS4 ha un campo ID utente ma non uno scambio standard equivalente della password; il server può comunque applicare regole di accesso.

Il normale scambio SOCKS5 di nome utente/password non cifra le credenziali. Avviene prima che l’applicazione stabilisca HTTPS con la destinazione, quindi quella connessione HTTPS successiva non protegge il precedente accesso al proxy. La cifratura del percorso client-proxy richiede una connessione protetta separata o un meccanismo di sicurezza esplicitamente supportato.

Durante il normale inoltro SOCKS, HTTPS protegge lo scambio dell’applicazione con il sito, con verifica dei certificati attiva e senza intercettazione TLS. Un protocollo applicativo non cifrato resta tale attraverso l’intermediario. Il solo supporto SOCKS5 o l’autenticazione tramite password non promettono traffico cifrato.

Il proxy conosce comunque l’IP del client che si connette, la destinazione richiesta e i tempi della connessione. La destinazione vede l’IP di uscita del proxy e riceve i dati applicativi indirizzati a sé. Cookie, accessi agli account e altri identificatori applicativi possono ancora identificare l’utente; cambiare versione SOCKS non li elimina.

Come SOCKS5 trasporta TCP e UDP

TCP fornisce un flusso ordinato di byte. Una richiesta nel browser, una chiamata API o una sessione SSH può usare una connessione TCP SOCKS quando il client supporta quel percorso e il proxy consente la destinazione. Il successo sulla porta 443 di un sito non dimostra che la porta di un’altra applicazione sia disponibile.

UDP invia datagrammi separati. Un client SOCKS5 apre prima una connessione di controllo TCP e richiede un relay tramite UDP ASSOCIATE. Il proxy restituisce l’indirizzo del relay e la porta UDP. Il client vi invia i datagrammi con intestazioni SOCKS che descrivono le destinazioni. Chiudere la connessione di controllo TCP termina questa associazione UDP; i datagrammi viaggiano separatamente dalla connessione di controllo, non dentro un normale flusso SOCKS CONNECT.

Sia l’applicazione sia il servizio devono supportare questo meccanismo e la rete deve consentire il percorso UDP. Un programma può completare un accesso TCP mentre la sua funzione vocale, di gioco o un’altra funzione UDP continua a non funzionare. Una richiesta HTTPS riuscita tramite SOCKS CONNECT dimostra l’inoltro TCP, non il funzionamento di UDP. QUIC usa UDP, ma la sua effettiva utilizzabilità dipende anche dal client e dall’intero percorso; la sola etichetta SOCKS5 non la dimostra.

Quando è utile SOCKS

SOCKS è utile quando un programma necessita di una connessione intermediaria mantenendo il proprio protocollo applicativo. Uno script può richiedere dati API tramite un IP di uscita assegnato, un client di trasferimento file può raggiungere un server remoto attraverso un percorso approvato e un’applicazione desktop compatibile può usare un proxy senza essere un browser web. Ogni caso dipende dal supporto SOCKS del client e dalle porte di destinazione consentite dal servizio.

Per il lavoro ripetuto con lo stesso account o server può essere adatta un’uscita fissa. Per attività separate può essere utile un servizio a rotazione. SOCKS4 e SOCKS5 non determinano questo comportamento: il servizio stabilisce l’IP di uscita, il suo tipo di rete, se altri clienti lo usano e quando cambia. La versione del protocollo non offre neppure una classifica di velocità; lunghezza del percorso, carico del server e banda disponibile influiscono sul risultato.

Il supporto del client può essere più limitato del protocollo. L’implementazione SOCKS5 integrata in Chrome risolve i nomi di destinazione tramite il proxy ma non esegue l’autenticazione SOCKS5 con nome utente/password né inoltra UDP. Un endpoint accessibile solo con password può quindi funzionare in curl e non tramite quell’impostazione integrata del browser. Un adattatore esterno è una parte separata della connessione, con capacità proprie.

Un proxy configurato all’interno di un programma si applica alle connessioni supportate da quel programma. Non configura un downloader o uno script separato. Analogamente, le impostazioni proxy di sistema influiscono sui programmi che le utilizzano. Quando un adattatore reindirizza le connessioni di un’applicazione priva di supporto SOCKS nativo, conta la sua copertura di TCP, UDP e DNS. SOCKS non fornisce un normale inoltro ICMP, quindi ping non verifica questo percorso proxy.

Impostazioni di connessione e un test utile

Inizia dall’indirizzo del proxy, dalla porta di ascolto, dalla versione SOCKS e dal metodo di accesso forniti per l’endpoint. Un numero come 1080 non identifica da solo il protocollo. Seleziona SOCKS nel client invece di inserire lo stesso indirizzo in un campo proxy esclusivamente HTTP.

Le credenziali proxy autorizzano l’uso dell’intermediario; un accesso al sito autorizza l’uso del sito. Appartengono a impostazioni diverse. In curl, --proxy-user fornisce le credenziali proxy, mentre --user fornisce quelle della destinazione. Per l’accesso tramite IP, l’elenco degli IP consentiti deve corrispondere all’IP di origine del client visto dal proxy, che può cambiare quando il client cambia rete.

Scegli la modalità DNS desiderata, poi controlla le eventuali regole di esclusione. Un proxy configurato può essere evitato per destinazioni incluse in un elenco di esclusione. In curl, NO_PROXY può causarlo; --noproxy "" elimina quelle esclusioni per una singola esecuzione quando vuoi testare deliberatamente il percorso proxy.

Esegui il test dal programma che svolgerà realmente il lavoro. Un endpoint di verifica IP o il log di un server di destinazione che controlli può mostrare l’IP di origine della richiesta. Confronta il risultato con una richiesta diretta. L’indirizzo usato per raggiungere il proxy e l’indirizzo di uscita visto dalla destinazione non devono necessariamente coincidere.

Prova poi l’attività reale. Un IP diverso dimostra il percorso della richiesta testata, ma non misura tutti i trasporti e non stabilisce come risponderà un altro sito. Testa separatamente UDP o IPv6 quando servono all’attività e valuta tempi di risposta e stabilità della connessione con un carico rappresentativo.

Individua un errore in base alla fase di connessione

Distingui tra raggiungere il proxy, ottenere accesso, aprire la connessione alla destinazione e ricevere la risposta applicativa. Queste fasi hanno cause di errore diverse.

Se una connessione HTTPS verificata riesce e il sito restituisce una pagina di accesso, un CAPTCHA o un rifiuto, la connessione SOCKS ha già trasportato quello scambio. Esamina la risposta del sito e il comportamento dell’applicazione. Se invece la richiesta mostra il tuo consueto IP pubblico, controlla il proxy selezionato e le regole di esclusione del programma.