Протоколи · 1 хв читання

Методи автентифікації SOCKS5 (RFC 1929)

Перш ніж передавати ваш трафік, SOCKS5-проксі домовляється про спосіб автентифікації. Розбираємо рукостискання з узгодженням методів із RFC 1928, схему логін/пароль із RFC 1929 і що це означає на практиці — включно із застереженням про передачу відкритим текстом.

Рукостискання з узгодженням методу

SOCKS5 (описаний у RFC 1928) не припускає жодного методу автентифікації — він його узгоджує. Щойно відкривається TCP-з'єднання до проксі, клієнт надсилає привітання зі списком методів, які підтримує, а проксі обирає один.

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

Ім'я користувача й пароль: RFC 1929

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

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

Лише після успішного статусу клієнт переходить до власне запиту SOCKS5 CONNECT із зазначенням призначення. Оскільки довжини імені та пароля кодуються одним байтом, кожне з них обмежене 255 байтами. Як це виглядає з реальними клієнтами, дивіться в посібнику з автентифікації на проксі, а роботу з обліковими даними — в API.

Застереження про відкритий текст і що з ним робити

RFC 1929 передає логін і пароль як відкритий текст між клієнтом і проксі. HTTPS до цільового сервісу не шифрує цей обмін автентифікації.

Використовуйте довірений мережевий шлях або зашифрований транспорт, який явно підтримує провайдер. Виділена IP-адреса не шифрує облікові дані й не замінює їх на поточних адресах s4m. Пов’язана тема: виділена IP-адреса.

FAQ

Відповіді на питання

Як SOCKS5 обирає метод автентифікації?

Узгодженням. Клієнт починає з привітання, де перелічує підтримувані методи (наприклад, 0x00 — без автентифікації і 0x02 — ім'я/пароль), а сервер відповідає єдиним обраним методом. Якщо сервер обрав 0x02, клієнт проходить обмін за RFC 1929 з іменем і паролем, і лише потім надсилає запит на з'єднання.

Чи шифрується автентифікація SOCKS5 за іменем і паролем?

RFC 1929 передає логін і пароль як відкритий текст між клієнтом і проксі. HTTPS до цільового сервісу не шифрує цей обмін автентифікації. Використовуйте довірений мережевий шлях або зашифрований транспорт, який явно підтримує провайдер. Виділена IP-адреса не шифрує облікові дані й не замінює їх на поточних адресах s4m. Пов’язана тема: виділена IP-адреса.

Чим RFC 1928 відрізняється від RFC 1929?

RFC 1928 описує сам SOCKS5, зокрема рукостискання, у якому клієнт і сервер узгоджують метод автентифікації. RFC 1929 описує лише один із цих методів — схему з іменем користувача й паролем — з власним байтом версії під-узгодження та форматом повідомлень. Вони працюють у парі.

SOCKS5 з автентифікацією, як належить

Налаштуйте доступ SOCKS5 або HTTP у s4m з обліковими даними свого акаунта.

Цю сторінку знаходять за запитами

Реальні пошукові фрази, на які відповідає ця сторінка — за посиланнями відкриються матеріали, що розкривають тему глибше.