Metodi di autenticazione SOCKS5 (RFC 1929)

SOCKS5 (definito in RFC 1928) non presuppone un metodo di autenticazione — lo negozia. Non appena la connessione TCP al proxy si apre, il client invia un saluto che elenca i metodi di autenticazione che supporta, e il proxy ne sceglie uno.

Il saluto del client è: un byte di versione (0x05), un conteggio dei metodi, poi tanti identificatori di metodo. I metodi comuni sono 0x00 "nessuna autenticazione richiesta", 0x02 "nome utente/password", e 0xFF "nessun metodo accettabile". Il server risponde con due byte: la versione e il singolo metodo che ha scelto. Se restituisce 0x00, ti connetti immediatamente; se restituisce 0x02, il client deve ora eseguire la sotto-negoziazione nome utente/password prima di poter emettere qualsiasi richiesta di connessione. Se il server restituisce 0xFF, nessuno dei metodi offerti era accettabile e chiude la connessione. Questo è il motivo per cui un proxy SOCKS5 s4m autenticato sulla porta 1080 si aspetta che il tuo client offra il metodo 0x02.

Il metodo username/password (0x02) è specificato separatamente in RFC 1929. È uno scambio piccolo e autonomo che avviene dopo la negoziazione del metodo e prima della richiesta SOCKS:

• Il client invia: un byte di versione della sub-negoziazione (0x01 — nota che questa è la versione di autenticazione, non la versione SOCKS), un byte per la lunghezza del nome utente, il nome utente, un byte per la lunghezza della password e la password.
• Il server risponde con due byte: la versione (0x01) e un byte di stato. 0x00 significa successo; qualsiasi altra cosa significa fallimento, e il server chiude la connessione.

Solo dopo uno stato di successo il client procede alla reale richiesta SOCKS5 CONNECT nominando la destinazione. Poiché sia il nome utente che la password sono prefissati da un byte di lunghezza, ciascuno è limitato a 255 byte. Vedi la nostra guida all'autenticazione proxy per come si svolge con i client reali e l'API per la gestione delle credenziali.

Il punto critico e onesto: RFC 1929 trasmette il nome utente e la password in testo semplice. I byte non sono criptati né hashati: chiunque possa osservare la connessione TCP tra te e il proxy può leggere le tue credenziali. La stessa RFC riconosce questo e avverte che il metodo è appropriato solo dove tale esposizione è accettabile.

Cosa significa questo in pratica: la sicurezza dell'autenticazione username/password di SOCKS5 dipende dal fatto che il percorso verso il proxy sia fidato, o dall'incapsulare l'intera connessione SOCKS in qualcosa di criptato. Le mitigazioni che le persone usano includono il tunneling di SOCKS5 su TLS o SSH, l'esecuzione del proxy su una rete fidata, o il fare affidamento sulla whitelist degli IP invece di (o in aggiunta a) credenziali — il che un IP dedicato rende pratico. Altri metodi di autenticazione SOCKS5 esistono in linea di principio (ad esempio GSS-API da RFC 1928), ma username/password rimane di gran lunga il più ampiamente implementato, quindi comprendere la sua natura in testo semplice — e non riutilizzare una password importante come credenziale del proxy — è importante.