Методы аутентификации SOCKS5 (RFC 1929)

SOCKS5 (описан в RFC 1928) не предполагает никакого метода аутентификации — он его согласует. Как только открывается TCP-соединение к прокси, клиент шлёт приветствие со списком поддерживаемых методов, а прокси выбирает один.

Приветствие клиента выглядит так: байт версии (0x05), число методов и столько же идентификаторов методов. Распространённые методы: 0x00 — «аутентификация не требуется», 0x02 — «имя пользователя/пароль» и 0xFF — «ни один метод не подходит». Сервер отвечает двумя байтами: версия и единственный выбранный метод. Если он возвращает 0x00, вы подключаетесь сразу; если 0x02, клиент обязан сначала пройти под-согласование с именем пользователя и паролем и только потом слать запрос на соединение. Если сервер возвращает 0xFF, ни один из предложенных методов не подошёл и он закрывает соединение. Именно поэтому прокси SOCKS5 s4m с аутентификацией на порту 1080 ожидает, что ваш клиент предложит метод 0x02.

Метод с именем пользователя и паролем (0x02) описан отдельно, в RFC 1929. Это крошечный самодостаточный обмен, происходящий после согласования метода и перед SOCKS-запросом:

• Клиент шлёт: байт версии под-согласования (0x01 — обратите внимание, это версия аутентификации, а не версия SOCKS), однобайтовую длину имени, само имя, однобайтовую длину пароля и пароль.
• Сервер отвечает двумя байтами: версия (0x01) и байт статуса. 0x00 означает успех; всё остальное — отказ, после которого сервер закрывает соединение.

Только после успешного статуса клиент переходит к самому запросу SOCKS5 CONNECT с указанием назначения. Поскольку длины имени и пароля кодируются одним байтом, каждое из них ограничено 255 байтами. Как это выглядит с реальными клиентами, смотрите в руководстве по аутентификации на прокси, а работу с учётными данными — в API.

RFC 1929 передаёт логин и пароль как открытый текст между клиентом и прокси. HTTPS до целевого сервиса не шифрует этот обмен аутентификации.

Используйте доверенный сетевой путь или шифрованный транспорт, который явно поддерживает провайдер. Выделенный IP не шифрует учётные данные и не заменяет их на текущих адресах s4m. Связанная тема: выделенный IP.