Логин и пароль в SOCKS5: как проходит проверка доступа
SOCKS5 не начинает с отправки логина и пароля. Клиент сначала объявляет поддерживаемые методы, а сервер выбирает один из них. Если выбран username/password, стороны выполняют отдельную под-процедуру, после которой клиент только приступает к команде соединения.
Главное за минуту
- Авторизация SOCKS5 следует после выбора метода.
- Успех авторизации не равен успеху соединения к назначению.
- Пароль не защищается шифрованием самим RFC 1929.
- Логи не должны содержать исходные реквизиты.
Выбор метода
Клиент отправляет список методов, который действительно умеет использовать. Сервер возвращает выбранный идентификатор либо значение, означающее отсутствие приемлемого метода. Несовпадение на этом этапе нельзя исправить сменой адреса назначения.
Под-процедура логина и пароля
RFC 1929 задаёт отдельную версию сообщения, длины и значения username/password. Сервер возвращает статус проверки. Ограничения длины и кодирования необходимо учитывать при генерации реквизитов и импорте в старые программы.
После успешной проверки
Клиент отправляет SOCKS-команду с назначением. Она может завершиться отказом правил, недоступностью сети или другой ошибкой, несмотря на правильный пароль. Пользовательский интерфейс должен различать результат авторизации и результат релея.
Защита реквизитов
Метод username/password не предоставляет собственной конфиденциальности. Сервис защищает участок до прокси доверенной сетью или дополнительным безопасным транспортом, хранит пароль в защищённом виде и предоставляет механизм его замены и отзыва.
Практический чек-лист
- 1Проверить, что клиент предлагает метод username/password.
- 2Отдельно показать этап авторизации и этап CONNECT.
- 3Генерировать совместимые логины без управляющих символов.
- 4Не выводить пароль в логах и уведомлениях.
- 5Сменить реквизиты при подозрении на раскрытие.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.