Metody uwierzytelniania SOCKS5 (RFC 1929)

SOCKS5 (zdefiniowany w RFC 1928) nie zakłada metody uwierzytelniania — negocjuje ją. Gdy tylko połączenie TCP z proxy zostanie otwarte, klient wysyła powitanie, w którym wymienia metody uwierzytelniania, które obsługuje, a proxy wybiera jedną z nich.

Powitanie klienta to: bajt wersji (0x05), liczba metod, a następnie tyle identyfikatorów metod. Powszechne metody to 0x00 "brak wymagań dotyczących uwierzytelniania", 0x02 "nazwa użytkownika/hasło" oraz 0xFF "brak akceptowalnych metod". Serwer odpowiada dwoma bajtami: wersją i jedną wybraną metodą. Jeśli zwróci 0x00, łączysz się od razu; jeśli zwróci 0x02, klient musi teraz przeprowadzić podnegocjację nazwy użytkownika/hasła, zanim będzie mógł wysłać jakiekolwiek żądanie połączenia. Jeśli serwer zwróci 0xFF, żadna z oferowanych metod nie była akceptowalna i zamyka połączenie. Dlatego uwierzytelnione s4m SOCKS5 proxy na porcie 1080 oczekuje, że twój klient zaoferuje metodę 0x02.

Metoda nazwy użytkownika/hasła (0x02) jest określona osobno w RFC 1929. Jest to mała, samodzielna wymiana, która odbywa się po negocjacji metody i przed żądaniem SOCKS:

• Klient wysyła: bajt wersji sub-negocjacji (0x01 — zauważ, że to jest wersja autoryzacji, a nie wersja SOCKS), bajt długości nazwy użytkownika, nazwę użytkownika, bajt długości hasła oraz hasło.
• Serwer odpowiada dwoma bajtami: wersją (0x01) i bajtem statusu. 0x00 oznacza sukces; cokolwiek innego oznacza niepowodzenie, a serwer zamyka połączenie.

Dopiero po uzyskaniu statusu sukcesu klient przechodzi do rzeczywistego żądania SOCKS5 CONNECT, wskazując cel. Ponieważ zarówno nazwa użytkownika, jak i hasło są prefiksowane długością jako pojedyncze bajty, każdy z nich jest ograniczony do 255 bajtów. Zobacz nasz przewodnik po autoryzacji proxy, aby zobaczyć, jak to wygląda w przypadku rzeczywistych klientów oraz API do obsługi poświadczeń.

Krytyczny uczciwy punkt: RFC 1929 przesyła nazwę użytkownika i hasło w czystym tekście. Bajty nie są szyfrowane ani haszowane — każdy, kto może obserwować połączenie TCP między tobą a proxy, może odczytać twoje dane uwierzytelniające. Sam RFC to przyznaje i ostrzega, że metoda ta jest odpowiednia tylko tam, gdzie takie narażenie jest akceptowalne.

Co to oznacza w praktyce: bezpieczeństwo uwierzytelniania za pomocą nazwy użytkownika/hasła SOCKS5 zależy od zaufania do ścieżki do proxy lub od owinięcia całego połączenia SOCKS w coś szyfrowanego. Środki zaradcze, z których korzystają ludzie, obejmują tunelowanie SOCKS5 przez TLS lub SSH, uruchamianie proxy w zaufanej sieci lub poleganie na białej liście adresów IP zamiast (lub oprócz) danych uwierzytelniających — co czyni praktycznym posiadanie dedykowanego IP. Inne metody uwierzytelniania SOCKS5 istnieją w teorii (na przykład GSS-API z RFC 1928), ale nazwa użytkownika/hasło pozostaje zdecydowanie najczęściej wdrażaną, więc zrozumienie jej czystego charakteru — i nieużywanie ważnego hasła jako danych uwierzytelniających proxy — ma znaczenie.