Dlaczego uwierzytelnianie hasłem SOCKS5 zaczyna się od wersji 1
Odróżnij powitanie SOCKS5 od pola wersji w jego podnegocjacji nazwy użytkownika/hasła.
Klient SOCKS5 zaczyna od wersji 5, a następnie podczas uwierzytelniania hasłem wysyła wersję 1. To niekoniecznie jest downgrade ani błędne proxy.
Pierwsza wymiana negocjuje metodę uwierzytelniania SOCKS5. Gdy wybrano nazwę użytkownika/hasło, RFC 1929 definiuje osobną podnegocjację, której polem wersji jest 0x01.
To żądanie uwierzytelnienia zawiera długości i bajty nazwy użytkownika oraz hasła. Serwer zwraca wersję podnegocjacji i status. Dopiero po pomyślnym uwierzytelnieniu klient wysyła żądanie celu SOCKS5.
Trzymaj obie wymiany osobno, czytając zrzut lub implementując klienta. Powtarzanie 0x05 wszędzie, bo usługa nazywa się SOCKS5, tworzy nieprawidłowy komunikat uwierzytelnienia.
Pomyślny status hasła nie oznacza też, że żądany cel jest dozwolony. Następna odpowiedź SOCKS nadal może odrzucić to połączenie.
Wreszcie ta metoda nazwy użytkownika/hasła nie szyfruje swoich poświadczeń. Bajt wersji oznacza format komunikatu, a nie tryb logowania szyfrowany lub silniejszy.