Почему аутентификация по паролю SOCKS5 начинается с версии 1
Отличайте приветствие SOCKS5 от поля версии в его субпереговорах имени пользователя и пароля.
Клиент SOCKS5 начинает с версии 5, а затем при аутентификации по паролю отправляет версию 1. Это не обязательно откат версии или неверный прокси.
Первый обмен согласует метод аутентификации SOCKS5. Когда выбраны имя пользователя и пароль, RFC 1929 определяет отдельные субпереговоры, поле версии которых — 0x01.
Этот запрос аутентификации содержит длины и байты имени пользователя и пароля. Сервер возвращает версию субпереговоров и статус. Только после успешной аутентификации клиент отправляет запрос назначения SOCKS5.
Держите два обмена раздельно, читая трассировку или реализуя клиент. Повторение 0x05 везде только потому, что служба называется SOCKS5, создаёт неверное сообщение аутентификации.
Успешный статус пароля также не означает, что запрошенное назначение разрешено. Следующий ответ SOCKS всё ещё может отклонить это соединение.
Наконец, этот метод имени пользователя и пароля не шифрует свои учётные данные. Байт версии обозначает формат сообщения, а не зашифрованный или более строгий режим входа.