Un client SOCKS5 începe cu versiunea 5, apoi trimite versiunea 1 în timpul autentificării prin parolă. Aceasta nu este neapărat o retrogradare sau un proxy greșit.

Primul schimb negociază metoda de autentificare SOCKS5. Când se alege nume de utilizator/parolă, RFC 1929 definește o subnegociere separată al cărei câmp de versiune este 0x01.

Acea cerere de autentificare include lungimi și octeți pentru numele de utilizator și parolă. Serverul returnează versiunea subnegocierii și un status. Abia după ce autentificarea reușește, clientul trimite cererea de destinație SOCKS5.

Păstrați cele două schimburi separate când citiți o urmă sau implementați un client. Repetarea 0x05 peste tot pentru că serviciul se numește SOCKS5 produce mesajul de autentificare greșit.

Un status de parolă reușit nu înseamnă nici că destinația solicitată este permisă. Următorul răspuns SOCKS poate totuși refuza acea conexiune.

În cele din urmă, această metodă nume de utilizator/parolă nu își criptează acreditările. Octetul de versiune identifică un format de mesaj, nu un mod de autentificare criptat sau mai puternic.

Articole similare