RFC 1928

RFC 1928 — это документ, опубликованный в марте 1996 года в серии Request for Comments (RFC) Инженерного совета Интернета (IETF), который описывает протокол SOCKS версии 5 (SOCKSv5). SOCKS является сетевым протоколом, предназначенным для организации прокси-серверов, обеспечивающих передачу сетевых пакетов между клиентом и сервером через промежуточный узел. RFC 1928 определяет механизм аутентификации, адресации и маршрутизации трафика на транспортном уровне (модель OSI, уровень 5 — сеансовый), что отличает его от прокси-серверов прикладного уровня (например, HTTP-прокси). Протокол поддерживает передачу данных по протоколам TCP и UDP, а также работу с IPv4, IPv6 и доменными именами.

История и предпосылки создания

До появления SOCKSv5 существовала версия протокола SOCKSv4, разработанная Дэвидом Кобласом и Йингом-Да Ли в начале 1990-х годов. SOCKSv4 позволял клиентам за брандмауэром (межсетевым экраном) устанавливать TCP-соединения с внешними серверами, однако имел существенные ограничения:

• отсутствие поддержки аутентификации;
• работа только с протоколом TCP;
• поддержка только IPv4-адресов.

К середине 1990-х годов рост Интернета и усложнение сетевой инфраструктуры потребовали более гибкого и безопасного решения. Рабочая группа IETF по протоколу SOCKS, возглавляемая Маркусом Лехом (Marcus Leech), разработала SOCKSv5, который был задокументирован в RFC 1928. Документ был принят в качестве предложения стандарта (Proposed Standard) и стал основой для многих реализаций прокси-серверов, включая широко распространённый Dante (разработанный компанией Inferno Nettverk A/S, Норвегия) и встроенные решения в операционных системах (например, в Linux через пакет socks5). В России протокол SOCKSv5 активно используется в корпоративных сетях и для обхода блокировок, хотя его применение регулируется федеральными законами «О связи» и «Об информации, информационных технологиях и о защите информации».

Архитектура и принцип работы

Протокол SOCKSv5 работает по модели «клиент — прокси-сервер — целевой сервер». Клиент (например, веб-браузер или почтовый клиент) инициирует соединение с SOCKS-прокси, который затем устанавливает соединение с целевым сервером от имени клиента. Взаимодействие делится на три этапа:

Установка соединения (Handshake)

Клиент отправляет прокси-серверу запрос, содержащий версию протокола (0x05 для SOCKSv5) и список поддерживаемых методов аутентификации. Прокси-сервер выбирает один из методов и отправляет ответ. Если аутентификация не требуется, используется метод «без аутентификации» (0x00). Возможные методы включают:

• 0x00 — без аутентификации;
• 0x01 — аутентификация по протоколу GSS-API (Generic Security Services Application Program Interface);
• 0x02 — аутентификация по имени пользователя и паролю (USERNAME/PASSWORD, определённая в RFC 1929);
• 0x03–0x7F — зарезервированные методы для IANA;
• 0x80–0xFE — методы, определённые частными реализациями.

Запрос на соединение (Request)

После успешной аутентификации клиент отправляет запрос на соединение, который содержит:

• версию протокола (0x05);
• код команды: 0x01 (CONNECT — установка TCP-соединения), 0x02 (BIND — привязка для входящих соединений, используется, например, для FTP в пассивном режиме), 0x03 (UDP ASSOCIATE — ассоциация для передачи UDP-дейтаграмм);
• тип адреса: 0x01 (IPv4), 0x03 (доменное имя), 0x04 (IPv6);
• адрес назначения (4 байта для IPv4, 16 байт для IPv6, или переменная длина для доменного имени);
• порт назначения (2 байта).

Прокси-сервер обрабатывает запрос и отправляет ответ, содержащий код ответа (например, 0x00 — успех, 0x01 — общая ошибка SOCKS, 0x02 — соединение запрещено правилами, 0x03 — сеть недоступна, 0x04 — хост недоступен, 0x05 — соединение отклонено, 0x06 — TTL истёк, 0x07 — команда не поддерживается, 0x08 — тип адреса не поддерживается) и адрес/порт, по которому прокси будет связываться с клиентом (для BIND и UDP ASSOCIATE).

Передача данных

После успешного ответа устанавливается прямой канал передачи данных между клиентом и целевым сервером через прокси-сервер. Для TCP-соединений данные передаются в обоих направлениях. Для UDP-дейтаграмм клиент отправляет данные на адрес и порт, указанные прокси-сервером в ответе на команду UDP ASSOCIATE, а прокси-сервер пересылает их целевому серверу.

Поддерживаемые протоколы и адресация

Одно из ключевых нововведений SOCKSv5 по сравнению с SOCKSv4 — поддержка UDP. Команда UDP ASSOCIATE позволяет прокси-серверу создать временную ассоциацию для передачи UDP-пакетов. Это важно для приложений, использующих UDP, таких как DNS-запросы, потоковое видео или онлайн-игры. Однако реализация UDP-проксирования сложнее, чем TCP, из-за отсутствия установления соединения и необходимости отслеживания состояния сессий.

Протокол поддерживает три типа адресов:

• IPv4 (4 байта);
• IPv6 (16 байт);
• доменные имена (переменная длина, до 255 символов).

Это делает SOCKSv5 универсальным средством для работы с современными сетями, включая переход на IPv6. В России, где активно внедряется IPv6 в государственных и корпоративных сетях (в соответствии с программой «Цифровая экономика»), поддержка IPv6 в SOCKSv5 является востребованной.

Аутентификация и безопасность

RFC 1928 определяет механизм согласования методов аутентификации, но не включает в себя конкретные реализации. Наиболее распространённые методы:

• Без аутентификации (0x00) — используется в доверенных сетях, например, в локальных сетях организаций.
• GSS-API (0x01) — обеспечивает интеграцию с системами Kerberos и другими механизмами единого входа (Single Sign-On). Широко применяется в корпоративных средах, в том числе в российских компаниях, использующих Active Directory.
• USERNAME/PASSWORD (0x02) — простой метод, описанный в RFC 1929. Клиент отправляет имя пользователя и пароль в открытом виде (без шифрования), поэтому рекомендуется использовать его только в сочетании с шифрованием на транспортном уровне (например, через TLS).

Безопасность SOCKSv5 зависит от конфигурации прокси-сервера. Для защиты от несанкционированного доступа администраторы могут:

• ограничивать доступ по IP-адресам;
• требовать аутентификацию;
• использовать шифрование трафика между клиентом и прокси (например, через SSH-туннель или OpenVPN).

В России использование SOCKS-прокси для обхода блокировок (например, доступа к сайтам, внесённым в Единый реестр запрещённой информации) может быть расценено как нарушение законодательства. При этом сам протокол не запрещён и широко применяется в законных целях, таких как обеспечение безопасности корпоративных сетей и управление доступом.

Применение

SOCKSv5 используется в различных сценариях:

Прокси-серверы для обхода ограничений

Благодаря поддержке TCP и UDP, SOCKSv5 часто применяется для обхода сетевых ограничений (например, корпоративных брандмауэров или государственных блокировок). Однако в России такие действия могут быть незаконными, если они направлены на доступ к запрещённому контенту.

Корпоративные сети

В организациях SOCKSv5 используется для централизованного управления доступом в Интернет, мониторинга трафика и обеспечения безопасности. Например, прокси-сервер Dante (разработанный компанией Inferno Nettverk A/S) популярен в российских компаниях благодаря гибкой настройке политик доступа и поддержке аутентификации.

Приложения, требующие UDP

SOCKSv5 является одним из немногих прокси-протоколов, поддерживающих UDP. Это делает его незаменимым для приложений, работающих с потоковым видео (например, IP-телевидение), онлайн-игр и VoIP-сервисов (например, Skype, Zoom). В России такие приложения активно используются в образовательных и медицинских учреждениях.

Торренты и P2P-сети

Клиенты BitTorrent часто поддерживают SOCKSv5 для анонимизации трафика. Однако в России распространение пиратского контента через торренты преследуется по закону, поэтому использование SOCKSv5 для этих целей может быть неправомерным.

Реализации и совместимость

Наиболее известные реализации SOCKSv5:

• Dante (Inferno Nettverk A/S) — коммерческий и open-source прокси-сервер, поддерживающий SOCKSv4 и SOCKSv5. Широко используется в Linux-системах.
• SS5 (Socks Server 5) — легковесный прокси-сервер с открытым исходным кодом, написанный на C.
• WinGate (Qbik New Zealand) — коммерческий прокси-сервер для Windows, поддерживающий SOCKSv5.
• Shadowsocks (разработанный Клэем Фаном, Китай) — хотя Shadowsocks не является реализацией SOCKSv5, он часто используется в связке с SOCKS-прокси для шифрования трафика.

Большинство современных операционных систем (Windows, macOS, Linux) имеют встроенную поддержку SOCKS-прокси на уровне системы или приложений. Например, в Linux можно настроить SOCKS-прокси через переменные окружения (например, SOCKS5_PROXY) или через конфигурацию браузера.

Критика и ограничения

Несмотря на широкое распространение, SOCKSv5 имеет ряд недостатков:

• Отсутствие шифрования — протокол не предусматривает шифрования трафика между клиентом и прокси-сервером. Для защиты данных требуется дополнительное шифрование (например, через TLS или SSH).
• Сложность настройки — для корректной работы с UDP требуются дополнительные конфигурации, что может вызывать проблемы у неопытных администраторов.
• Уязвимость к атакам — при неправильной настройке прокси-сервер может быть использован для ретрансляции трафика (open proxy), что может привести к злоупотреблениям (например, рассылке спама или DDoS-атакам). В России использование открытых прокси-серверов может быть расценено как нарушение закона «О связи».

Интересные факты

• RFC 1928 является одним из немногих стандартов IETF, который не был существенно изменён с момента публикации. Последующие документы (RFC 1929, RFC 1961) лишь дополняли его, но не заменяли.
• Протокол SOCKSv5 поддерживается в браузерах (например, Firefox, Chrome) через настройки прокси-сервера, а также в клиентах для работы с электронной почтой (например, Thunderbird).
• В России SOCKSv5 активно используется в государственных информационных системах, таких как Единая система межведомственного электронного взаимодействия (СМЭВ), для обеспечения безопасного доступа к ресурсам.

Источники

• RFC 1928 — SOCKS Protocol Version 5 (M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones, март 1996).
• RFC 1929 — Username/Password Authentication for SOCKS V5 (M. Leech, март 1996).
• RFC 1961 — GSS-API Authentication for SOCKS V5 (J. Kohl, C. Neuman, июнь 1996).
• «SOCKS Protocol Version 5» — описание на сайте IETF.
• «Dante — A SOCKS Server» — документация Inferno Nettverk A/S.
• «Обзор протокола SOCKSv5» — техническая статья на сайте Habr (Россия).