Протокол SingLink тепер з відкритим кодом

Сьогодні 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.

SingLink 2.0 і відкритий протокол SingLink — це різні протоколи

Офіційні застосунки SingLinkVPN працюють на наших робочих протоколах, зокрема на SingLink 2.0. Основний вихідний код SingLink 2.0 не входить до цього релізу й залишається закритим.

Протокол SingLink, опублікований сьогодні, — відкритий протокол SingLink, коли його потрібно відрізнити від SingLink 2.0, — це окремий протокол, який 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 високого рівня, 14 середнього, решта — низького рівня або інформаційні. Жодна з них не порушувала конфіденційність чи автентифікацію трафіку користувачів. Усі знахідки високого й середнього рівня виправлено або пом'якшено, для кожної є регресійний тест, а кожен парсер покрито фаз-тестами.
• Незалежного аудиту ще не було. Радимо не покладатися на протокол у сценаріях із високим ризиком, доки він не пройде незалежний аудит, який ми плануємо провести, перш ніж оголосити його стабільним.
• Перший пакет не має прямої секретності. Його захищає довгостроковий ключ сервера, тож ключі серверів слід регулярно змінювати. Ротацію ключів підтримано.
• Не перевірявся на практиці в материковому Китаї. Його відбиток TLS і розмір першого пакета все ще можна розрізнити. Для користувачів у материковому Китаї офіційні застосунки SingLinkVPN і далі використовують наші наявні робочі протоколи.
• Серверу потрібен власний домен, сертифікат, який приймають браузери, і справжній вебсайт за ним.

Спробуйте та долучайтеся

З Go 1.24 або новішою версією make test запускає набір тестів, make cli збирає інструмент командного рядка, а singlink demo запускає локальні сервер і клієнт на одному комп'ютері. README у репозиторії пояснює, як запустити сервер.

Запитання, звіти про помилки та Pull Request вітаються на GitHub. Про вразливості безпеки, будь ласка, повідомляйте приватно, а не в публічному Issue, — порядок описано в SECURITY.md.

Ліцензія та торговельні марки

Код поширюється за ліцензією Apache-2.0: ви можете використовувати, змінювати й повторно поширювати його, зокрема в комерційних цілях, на умовах ліцензії. Назви "SingLink" і "SingLinkVPN" та логотип є торговельними марками SingLinkLabs, і ліцензія не дає дозволу використовувати їх інакше, ніж для зазначення походження роботи. Змінені версії та форки слід публікувати під власною назвою та з власною іконкою.

Додаткові матеріали

• Прототип застосунку SingLinkVPN тепер з відкритим кодом — і його код на GitHub
• Проєкти SingLinkLabs з відкритим кодом
• Технічна документація (whitepaper) SingLink 2.0 — робочий протокол офіційних застосунків