Métodos de Autenticação SOCKS5 (RFC 1929)

SOCKS5 (definido em RFC 1928) não assume um método de autenticação — ele negocia um. Assim que a conexão TCP com o proxy é aberta, o cliente envia uma saudação listando os métodos de autenticação que suporta, e o proxy escolhe um.

A saudação do cliente é: um byte de versão (0x05), uma contagem de métodos, e então tantos identificadores de método. Os métodos comuns são 0x00 "nenhuma autenticação necessária", 0x02 "nome de usuário/senha", e 0xFF "nenhum método aceitável". O servidor responde com dois bytes: a versão e o único método que escolheu. Se retornar 0x00, você se conecta imediatamente; se retornar 0x02, o cliente deve agora executar a sub-negociação de nome de usuário/senha antes de poder emitir qualquer solicitação de conexão. Se o servidor retornar 0xFF, nenhum dos métodos oferecidos era aceitável e ele fecha a conexão. É por isso que um proxy SOCKS5 s4m SOCKS5 autenticado na porta 1080 espera que seu cliente ofereça o método 0x02.

O método de nome de usuário/senha (0x02) é especificado separadamente no RFC 1929. É uma troca pequena e autônoma que acontece após a negociação do método e antes da solicitação SOCKS:

• O cliente envia: um byte de versão de sub-negociação (0x01 — note que esta é a versão de autenticação, não a versão SOCKS), um comprimento de nome de usuário de um byte, o nome de usuário, um comprimento de senha de um byte e a senha.
• O servidor responde com dois bytes: a versão (0x01) e um byte de status. 0x00 significa sucesso; qualquer outra coisa significa falha, e o servidor fecha a conexão.

Somente após um status de sucesso o cliente prossegue para a solicitação SOCKS5 CONNECT real nomeando o destino. Como tanto o nome de usuário quanto a senha são prefixados por comprimento de um byte, cada um é limitado a 255 bytes. Veja nosso guia de autenticação de proxy para como isso se desenrola com clientes reais e a API para manipulação de credenciais.

O ponto crítico e honesto: o RFC 1929 transmite o nome de usuário e a senha em texto simples. Os bytes não são criptografados ou hashados — qualquer um que possa observar a conexão TCP entre você e o proxy pode ler suas credenciais. O próprio RFC reconhece isso e alerta que o método é apropriado apenas onde essa exposição é aceitável.

O que isso significa na prática: a segurança da autenticação de nome de usuário/senha do SOCKS5 depende do caminho para o proxy ser confiável, ou de envolver toda a conexão SOCKS em algo criptografado. As mitig ações que as pessoas usam incluem tunelamento SOCKS5 sobre TLS ou SSH, executando o proxy em uma rede confiável, ou dependendo da lista de permissões de IP em vez de (ou além de) credenciais — o que um IP dedicado torna prático. Outros métodos de autenticação SOCKS5 existem em princípio (por exemplo, GSS-API do RFC 1928), mas nome de usuário/senha continua sendo de longe o mais amplamente implementado, então entender sua natureza em texto simples — e não reutilizar uma senha importante como credencial de proxy — é importante.