Архітектура та безпека

1Компоненти#

Розширення браузера. 38 КБ, ванільний JavaScript, без мініфікації та обфускації — код можна прочитати цілком. Керує маршрутизацією через штатні механізми браузера: PAC у Chrome і Proxy API у Firefox. Не потребує прав адміністратора, не встановлює драйверів, не змінює системні маршрути й DNS.

Шлюз. Бінарник 8 МБ на Go, без залежностей і конфігураційних файлів. Усі налаштування й сертифікати отримує від панелі керування захищеним каналом і застосовує на льоту. Стан зберігає локально, щоб переживати перезапуски й втрату звʼязку.

Панель керування (CP). Вебінтерфейс і API. Зберігає конфігурацію, видає налаштування шлюзам і розширенням, веде облік пристроїв і лімітів.

2Шлях запиту#

Браузер ──TLS──► Шлюз ──TLS──► Цільовий сервер
   │
   └── незахищені домени ──► напряму в інтернет

1. Розширення отримує за токеном список захищених доменів і правила маршрутизації.
2. Браузер спрямовує запити до цих доменів на шлюз методом CONNECT, решту — напряму.
3. Шлюз перевіряє підключення, резолвить імʼя власним резолвером (враховуючи перевизначення IP і порту, задані адміністратором) і встановлює зʼєднання з цільовим сервером.
4. Далі шлюз лише перекладає байти між сокетами.

Ключовий наслідок: маршрут обирається за доменом, а не глобально для браузера. Через шлюз іде рівно те, що перелічено в токені.

3Ідентифікація пристроїв#

Токен — це запрошення, а не посвідчення особи. Особистістю в системі є пристрій.

Під час встановлення розширення реєструється й отримує ідентифікатор пристрою (dev_id) і секретний ключ. Вони зберігаються окремо від токенів і не скидаються під час очищення даних браузера — лише під час видалення розширення.

Кожен запит до API супроводжується:

• ідентифікатором пристрою
• позначкою часу
• підписом HMAC-SHA256

Це дає три ефекти:

API розрізняє користувачів одного токена. Один токен, виданий трьом аудиторам, — це три різні пристрої з окремою статистикою й окремим відкликанням.

Перебір токенів ускладнено. Звернутися до API анонімно не можна: потрібен зареєстрований dev_id із валідним підписом. Спроби перебору привʼязані до конкретного пристрою й обриваються за ним, а не за IP, яку легко змінити.

Повтори запитів не проходять. Позначка часу в підписі захищає від replay-атак.

4Що захищає токен#

Пʼять символів в алфавіті base58 (регістр значущий) — це ідентифікатор доступу, а не єдиний барʼєр. Навіть знаючи токен, стороння людина не отримає доступу, тому що:

• звернутися до API можна лише із зареєстрованого пристрою з валідним підписом;
• кількість активацій обмежена — коли ліміт вичерпано, нові пристрої не підключаються;
• токен може мати вікно активації, за межами якого він не працює;
• токен може бути захищений паролем: конфігурація завантажується зашифрованою, без пароля не розшифровується;
• кожен підключений пристрій видимий адміністратору й відкликається окремо.

Токени з паролем починаються з великого символу — це видно за написанням, тому пароль очікується одразу.

Політики на рівні домену#

Вимоги безпеки можна закріпити за самим ресурсом, а не за кожним токеном:

• Лише захищений токен — будь-який токен, що включає такий домен, мусить мати пароль. Панель керування не дасть створити його без пароля.
• Лише приватна сесія — токен із таким доменом примусово працює в приватному режимі розширення: під час закриття браузера токен і конфігурація забуваються.

Це захист від людської помилки: позначка ставиться один раз на чутливий ресурс і діє для всіх майбутніх токенів, незалежно від того, хто і чи поспіхом їх створює.

Політики застосовуються fail-closed, але без розриву робочого доступу: додати захищений домен до незахищеного токена не можна, а якщо політику увімкнули пізніше — у наявних токенах домен стає вимкненим, і увімкнути його можна лише після виконання вимоги. Змінювати політики домену мають право лише власник воркспейсу та адміністратор; менеджеру це недоступно.

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

5Невидимість шлюзу#

Шлюз не відповідає нікому, крім зареєстрованих пристроїв, і не повідомляє про себе нічого.

Унікальна адреса на пристрій. Кожен пристрій підключається до шлюзу за власним іменем хоста. У публічному DNS і в сертифікаті присутній лише wildcard — конкретні імена ніде не публікуються. Це важливо через Certificate Transparency: сертифікати на кожен пристрій означали б публічний список усіх пристроїв, wildcard таке витікання унеможливлює.

Передавторизація за SNI. Шлюз перевіряє імʼя хоста в TLS-хендшейку перш за все інше. Якщо імʼя не очікується, зʼєднання скидається: ні ServerHello, ні сертифіката, ні TLS-alert. Тип alert сам по собі є відбитком, тому він не надсилається.

Однакова реакція на будь-яке сміття. Звичайний HTTP-запит і невалідний TLS отримують те саме скидання зʼєднання — визначити за відповіддю, який протокол очікується на порту, не можна.

Бан за IP. Джерело невдалої проби потрапляє до блокування.

Що бачить сканер: порт приймає TCP-зʼєднання. Більше нічого — ні банера, ні сертифіката, ні коду помилки.

6Шифрування трафіку#

Публічні сайти: наскрізне шифрування. Шлюз виконує маршрутизацію за SNI і не термінує TLS. Сесія шифрується між браузером і вашим сервером; шлюз бачить імʼя домену й обсяг переданих байтів, але не вміст. Розшифрувати трафік він технічно не може — ключів у нього немає.

Внутрішні сервіси по HTTP: термінація на вашому боці. Якщо сервіс працює без TLS (наприклад, Grafana на 127.0.0.1:3000), шлюз ставиться на ту саму машину або в ту саму мережу й термінує TLS локально, звертаючись до сервісу петлею або приватною адресою. Незашифрована ділянка не покидає вашу машину чи вашу мережу.

В обох випадках відкритий трафік не проходить публічними мережами.

7Синхронізація налаштувань#

Шлюзи отримують налаштування від панелі керування постійним зʼєднанням.

Інкрементально. Передаються лише зміни, а не повна конфігурація всіх користувачів. Це робить застосування швидким незалежно від розміру інсталяції.

На льоту. Нові налаштування застосовуються без перезапуску й без розриву поточних зʼєднань. Якщо користувачу додали трафік у момент, коли він качає файл, завантаження не перерветься.

Зі збереженням стану. Шлюз зберігає конфігурацію локально й продовжує працювати, коли втрачає звʼязок із панеллю керування — включно з перезавантаженням сервера.

8Відкликання доступу#

Відкликання пристрою або зміна лімітів доїжджає до шлюзів за секунди й застосовується негайно: перезапуск браузера користувачу не допоможе.

Важливе обмеження. Якщо шлюз у момент відкликання недоступний для панелі керування, зміна застосується після відновлення звʼязку. Автономність шлюзів — те, що захищає від простою за проблем на нашому боці, але вона ж означає, що вікно поширення відкликання дорівнює часу відновлення звʼязку. За звичайних умов це секунди.

9Сценарії відмови#

Панель керування недоступна. Шлюзи продовжують працювати з останньою відомою конфігурацією. Нові пристрої підключити не можна, наявний доступ зберігається. Зміни налаштувань застосуються після відновлення.

Шлюз недоступний. Захищені сайти не відкриваються в тих, хто ходить через цей шлюз. Решта трафіку браузера не зачеплена. Домени можна перемкнути на інший шлюз у панелі керування.

Розширення видалено. Доступ припиняється, у системі нічого не лишається. Повторне встановлення потребуватиме нової активації токена.

Користувач загубив пристрій. Відкличте його dev_id — доступ припиниться, інші користувачі того самого токена не зачеплені.

10Що ми бачимо і чого не бачимо#

Бачимо:

• до яких доменів підключалися пристрої та коли
• обсяг переданого трафіку
• ідентифікатори пристроїв і статистику їхньої активності
• події сканування шлюзів (телеметрія захисту)

Не бачимо:

• вміст трафіку до публічних сайтів — він зашифрований наскрізним TLS
• паролі, куки, дані форм, вміст сторінок
• трафік до доменів, яких немає в токенах, — він узагалі не проходить через нашу інфраструктуру

Не бачимо за self-hosted шлюзу: нічого з трафіку взагалі — він не проходить через нашу інфраструктуру в жодному вигляді. Панель керування в цьому разі обмінюється зі шлюзом лише конфігурацією та статистикою.

Відомі обмеження#

Чесний список, щоб не витрачати ваш час на перевірку:

• Лише HTTP/HTTPS у браузері. SSH, бази даних, доступ із CLI не підтримуються. Клієнт для TCP-over-HTTPS у планах.
• Шлюз має бути доступним ззовні. Робота за NAT без прокидання портів неможлива.
• ECH не використовується. Браузери не застосовують Encrypted Client Hello до проксі-зʼєднань, тому спостерігач на шляху (провайдер, корпоративний DPI) бачить імʼя хоста, за яким пристрій підключається до шлюзу. Імʼя псевдонімне й без ключів пристрою марне.
• Один домен — один маршрут одночасно в межах браузера.