Perché l'autenticazione con password SOCKS5 inizia con la versione 1
Distinguere il saluto SOCKS5 dal campo versione nella sua sotto-negoziazione nome utente/password.
Un client SOCKS5 inizia con la versione 5, poi invia la versione 1 durante l'autenticazione con password. Non è necessariamente un downgrade né un proxy errato.
Il primo scambio negozia il metodo di autenticazione SOCKS5. Quando viene scelto nome utente/password, la RFC 1929 definisce una sotto-negoziazione separata il cui campo versione è 0x01.
Tale richiesta di autenticazione include lunghezze e byte per il nome utente e la password. Il server restituisce la versione della sotto-negoziazione e uno stato. Solo dopo il successo dell'autenticazione il client invia la richiesta di destinazione SOCKS5.
Tenere separati i due scambi quando si legge una traccia o si implementa un client. Ripetere 0x05 ovunque perché il servizio si chiama SOCKS5 produce il messaggio di autenticazione sbagliato.
Uno stato della password riuscito non significa nemmeno che la destinazione richiesta sia consentita. La successiva risposta SOCKS può comunque rifiutare quella connessione.
Infine, questo metodo nome utente/password non cifra le sue credenziali. Il byte di versione identifica un formato di messaggio, non una modalità di accesso cifrata o più forte.