Сегодня SingLinkLabs, команда, которая создаёт SingLinkVPN, опубликовала на GitHub полный исходный код протокола SingLink под лицензией Apache-2.0. Теперь любой желающий может прочитать спецификацию, запустить код, проверить его безопасность и строить на его основе собственные решения.

Объявляя план открытия исходного кода SingLinkVPN, мы обещали поэтапно опубликовать VPN-протокол и VPN-клиент. Это и есть тот самый этап. Протокол выходит вместе с первым прототипом приложения SingLinkVPN, которое работает на нём, — подробнее в статье «Прототип приложения SingLinkVPN стал открытым».

Репозиторий: SingLinkLabs / singlink-protocol · Версия: 1.0.0-draft (имя в протоколе передачи SingLink/1, черновик спецификации 2) · Лицензия: Apache-2.0 · Язык: Go, только стандартная библиотека

Что опубликовано

  • Спецификация. SPEC.md описывает формат передачи данных байт за байтом, поэтому протокол можно реализовать независимо.

  • Библиотека протокола на Go. Она использует только криптографию из стандартной библиотеки Go и не имеет сторонних зависимостей.

  • Утилита командной строки для генерации ключей, выдачи пропусков доступа, создания ссылок подключения, запуска узла и клиента, а также демонстрации на одном компьютере.

  • Локальный прокси для приложений (SOCKS5 и HTTP) и интерфейс библиотеки на C (libsinglink), чтобы приложения на любой платформе могли встроить протокол.

  • Примеры развёртывания: образец конфигурации узла и защищённый служебный файл systemd.

  • Внутренний аудит безопасности со всеми найденными проблемами и исправлениями: SECURITY-AUDIT.md.

Официальные приложения SingLinkVPN работают на наших рабочих протоколах, в том числе на SingLink 2.0. Основной исходный код SingLink 2.0 в этот релиз не входит и остаётся закрытым.

Опубликованный сегодня протокол SingLink (когда его нужно отличить от SingLink 2.0, мы называем его открытым протоколом SingLink) — это отдельный протокол, который SingLinkLabs спроектировала с нуля для открытой разработки. Официальные приложения сейчас его не используют. Для существующих пользователей ничего не меняется: те же приложения, тот же аккаунт и те же подключения.

Зачем мы открываем исходный код

  • Заявления о безопасности должны быть проверяемыми. Постквантовый обмен ключами, привязку к устройству и устойчивость к зондированию легко заявить. Когда код и спецификация открыты, проверить их может каждый.

  • Чем больше глаз, тем быстрее находятся проблемы. Внешние исследователи и инженеры заметят то, что упустила внутренняя команда.

  • Другие смогут строить на его основе. Разработчики могут тестировать протокол, встраивать его в свои проекты и предлагать улучшения.

  • Мы выполняем свой план. Публикация протокола была одним из обещанных этапов.

Как это работает — простыми словами

Суть в одном предложении: со стороны кажется, что пользователь просто заходит на обычный HTTPS-сайт. Внутри спрятан зашифрованный запрос на доступ, и сервер передаёт трафик только для того, у кого есть действительный пропуск.

В конструкции используются три ключа. Представьте себе систему безопасности офисного здания:

  • Ключ узла — замок на двери. У каждого сервера он свой. Открыть запрос пользователя может только этот сервер, и это заодно доказывает, что пользователь попал на настоящий сервер.

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

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

Серверу достаточно знать, как выглядит печать, чтобы самостоятельно проверить пропуск. Поэтому узлы не ведут базу пользователей и не хранят пользовательские данные.

Что происходит при одном подключении

  1. Приложение открывает соединение, которое выглядит как обычное HTTPS-подключение к сайту.

  2. Первый пакет содержит одноразовый ключ для этого соединения, постквантовый шифротекст и запечатанную часть с адресом назначения, пропуском доступа, первыми реальными данными объёмом до 8 KB и подписью устройства над всем запросом. Дополнительный обмен туда и обратно не нужен.

  3. Сервер проверяет всё: может ли он расшифровать запрос, подлинна ли печать, совпадает ли подпись устройства, верно ли время, а также что запрос не является повтором, не просрочен и не отозван.

  4. Только если все проверки пройдены, сервер отвечает и начинает передавать трафик. Если хотя бы одна проверка не пройдена, соединение без изменений передаётся настоящему сайту. Тот, кто зондирует сервер, видит лишь обычный сайт, без разницы во времени ответа.

  5. Обе стороны объединяют свои одноразовые ключи в сеансовые ключи этого соединения. Данные шифруются блоками, первые блоки дополняются заполнением, а ключи автоматически заменяются после определённого объёма использования.

Свойства безопасности

  • Два уровня шифрования. Снаружи HTTPS, внутри собственный уровень протокола на AES-256-GCM, поэтому даже CDN, который завершает HTTPS, не видит содержимое.

  • Постквантовая защита. Обмен ключами сочетает классический X25519 с ML-KEM-768 (FIPS 203). Атакующему пришлось бы взломать оба.

  • Прямая секретность. Каждое соединение использует одноразовые ключи, поэтому взлом сервера в будущем не позволит расшифровать прошлый трафик. Исключение — первый пакет (см. ограничения ниже).

  • Привязка к устройству. Пропуск доступа, скопированный откуда-либо, бесполезен без ключа устройства, для которого он был выдан.

  • Защита от повторов. Повторная отправка перехваченного пакета не сработает, даже после перезапуска сервера.

  • Устойчивость к зондированию. Просроченные, отозванные, повторённые или поддельные запросы обрабатываются одинаково: их передают настоящему сайту.

  • Централизованное управление. Когда аккаунт или устройство отзывают, его активные подключения на всех серверах закрываются примерно за 10 секунд.

  • Защищённые серверы. Ограничения числа подключений на сервер и на IP, бюджет CPU для рукопожатий и полный список блокировки частных адресов и адресов специального назначения.

Откуда взяты идеи

Протокол SingLink опирается на проверенные решения: подключение одним запросом из VLESS и Trojan, передачу неудачных подключений настоящему сайту из Trojan и obfs4, шаблон рукопожатия Noise NK, вывод ключей и обработку 0-RTT из TLS 1.3, гибридный постквантовый обмен ключами из проекта стандарта X-Wing, блочное шифрование из Shadowsocks AEAD, подписанные токены из JWT и PASETO, привязанные к устройству токены из OAuth DPoP, HAProxy PROXY protocol, а также защиту от повторов и от перегрузки из WireGuard.

Заимствованы только идеи конструкции. Весь код написан с нуля. Код из Xray, V2Ray, sing-box или WireGuard не используется.

Текущий статус и известные ограничения

  • Это черновик. Версия — 1.0.0-draft, формат передачи данных ещё может измениться.

  • Пока проведён только внутренний аудит безопасности. Два специалиста по отдельности изучили криптографическую конструкцию и реализацию и зафиксировали 31 замечание: 2 уровня High, 14 уровня Medium, остальные — Low или информационные. Ни одно из них не нарушало конфиденциальность или аутентификацию пользовательского трафика. Все замечания уровней High и Medium исправлены или смягчены, для каждого есть регрессионный тест, а все парсеры покрыты фаззинг-тестами.

  • Стороннего аудита пока не было. Мы не рекомендуем полагаться на протокол в сценариях с высоким риском, пока он не пройдёт независимый аудит, который мы планируем провести до того, как назовём его стабильным.

  • Первый пакет не обладает прямой секретностью. Он защищён долгосрочным ключом сервера, поэтому ключи серверов следует регулярно менять. Смена ключей поддерживается.

  • Протокол не проверялся в реальных условиях в материковом Китае. Его отпечаток TLS и размер первого пакета пока можно распознать. Для пользователей в материковом Китае официальные приложения SingLinkVPN продолжают использовать наши существующие рабочие протоколы.

  • Серверу нужен собственный домен, сертификат, которому доверяют браузеры, и настоящий сайт за ним.

Попробуйте и присоединяйтесь

С Go 1.24 или новее make test запускает набор тестов, make cli собирает утилиту командной строки, а singlink demo запускает локальные сервер и клиент на одном компьютере. Как запустить сервер, описано в README репозитория.

Вопросы, сообщения об ошибках и Pull Request приветствуются на GitHub. Об уязвимостях безопасности, пожалуйста, сообщайте конфиденциально, а не в публичном Issue — порядок описан в SECURITY.md.

Лицензия и товарные знаки

Код распространяется под лицензией Apache-2.0: его можно использовать, изменять и распространять, в том числе в коммерческих целях, на условиях лицензии. Названия «SingLink» и «SingLinkVPN» и логотип являются товарными знаками SingLinkLabs, и лицензия не даёт права использовать их сверх указания на происхождение работы. Изменённые версии и форки следует публиковать под собственным названием и со своей иконкой.

Читайте также