Чому автентифікація паролем SOCKS5 починається з версії 1
Відрізняйте привітання SOCKS5 від поля версії в його субпереговорах імені користувача та пароля.
Клієнт SOCKS5 починає з версії 5, а потім під час автентифікації паролем надсилає версію 1. Це не обов'язково відкат версії чи неправильний проксі.
Перший обмін узгоджує метод автентифікації SOCKS5. Коли вибрано ім'я користувача та пароль, RFC 1929 визначає окремі субпереговори, поле версії яких — 0x01.
Цей запит автентифікації містить довжини та байти імені користувача й пароля. Сервер повертає версію субпереговорів і статус. Лише після успішної автентифікації клієнт надсилає запит призначення SOCKS5.
Тримайте два обміни окремо, читаючи трасування або реалізуючи клієнт. Повторення 0x05 усюди лише тому, що служба називається SOCKS5, створює неправильне повідомлення автентифікації.
Успішний статус пароля також не означає, що запитане призначення дозволене. Наступна відповідь SOCKS усе ще може відхилити це з'єднання.
Нарешті, цей метод імені користувача й пароля не шифрує свої облікові дані. Байт версії позначає формат повідомлення, а не зашифрований чи суворіший режим входу.