[Ciko 0]

Чому базовий Tor детектується і блокується

Перше, що потрібно зрозуміти - Tor ніколи не був спроектований як інструмент, що приховує факт свого використання. Його завдання – анонімізувати зміст та маршрут трафіку, а не маскувати протокол. Проблема в тому, що стандартний Tor-хендшейк має впізнавану сигнатуру на рівні протоколу — конкретну структуру TLS-сертифікатів, патерни розмірів пакетів, специфічні байтові послідовності при установці з'єднання з вузлом мережі.

Системи Deep Packet Inspection (DPI), які масово розгорнуті в країнах з державним контролем трафіку, не потребують розшифрування вмісту, щоб заблокувати Tor – їм достатньо розпізнати саму сигнатуру протоколу на льоту та скинути з'єднання. Додатково списки IP-адрес публічних Tor-вузлів відкриті (це частина архітектури - directory authorities публікують consensus з адресами relay-вузлів), тому блокування IP теж тривіальна для державного провайдера. Виходить подвійна проблема: блокування за сигнатурою протоколу та блокування за відомими адресами вхідних вузлів.

Bridges – вирішення проблеми відомих адрес

Bridge-вузли – це вхідні точки в мережу Tor, які не публікуються у відкритому consensus-каталозі. Замість того, щоб тягнути список вхідних вузлів з публічного джерела, який так само доступний і цензору, користувач отримує адреси мостів через альтернативні закриті канали — запит по email з певного поштового домену, через сайт із captcha-захистом від масового скрейпінгу, або через закриті канали розповсюдження всередині довірених спільнот.

Це вирішує проблему блокування IP, але не вирішує проблему сигнатури протоколу — DPI все ще може розпізнати сам факт використання Tor-протоколу, навіть якщо не знає заздалегідь, що конкретний IP відноситься до Tor-мережі, просто аналізуючи характер трафіку в реальному часі.

Pluggable transports — маскування самого протоколу

Ось тут починається по-справжньому цікава частина, тому що різні pluggable transports вирішують завдання маскування абсолютно різними методами, і я вважаю важливим розуміти різницю, а не сприймати їх як взаємозамінні опції у списку.

obfs4— це обфускація лише на рівні випадкового шуму. Протокол додає криптографічний шар поверх Tor-трафіку, роблячи його статистично схожим на випадкові байти без відомої структури. Для DPI-системи, яка шукає конкретні сигнатури протоколів, такий трафік не матчиться під один відомий шаблон — він просто виглядає як незрозумілий шум. Слабке місце такого підходу — сам факт наявності трафіку, який виглядає як чистий шум без видимої структури, в деяких конфігураціях DPI теж може вважатися підозрілим патерном, тому що легітимний звичайний трафік (HTTP, відео, звичайний TLS) має впізнавану статистичну структуру, а чистий шум на неї не походить.

meek - принципово інший підхід, заснований на маскування через domain fronting. Ідея в тому, щоб сховати Tor-трафік усередині звичайного HTTPS-з'єднання до великого хмарного провайдера (історично використовувалися Google App Engine, Amazon CloudFront, Microsoft Azure). З погляду цензора зовні видно лише TLS-з'єднання до домену великої хмарної платформи — а такі домени цензор фізично не може заблокувати повністю, тому що на тій же інфраструктурі висять тисячі легітимних сервісів, і блокування означало б відрізати доступ до величезного шматка звичайного інтернету. Реальний Tor-трафік всередині тунелюється через цю хмарну інфраструктуру до цього bridge-вузла. Слабкість цього методу – великі хмарні провайдери періодично закривають domain fronting як фічу на рівні інфраструктури саме тому, що її одночасно використовують і для обходу цензури, і для маскування шкідливого трафіку, і компаніям не хочеться бути посередині цього конфлікту.

Snowflake — на мій погляд, найвитонченіший із сучасних підходів. Замість постійної інфраструктури на стороні хмарних провайдерів, Snowflake використовує тимчасові WebRTC-з'єднання через браузери звичайних добровольців по всьому світу, які встановили розширення або просто тримають відкриту вкладку з проксі-кодом. Трафік користувача в країні, що цензурується, встановлює WebRTC-з'єднання до випадкового добровольчого "сноуфлейку", який і прокидає його далі в мережу Tor. З погляду DPI це виглядає як звичайний WebRTC-трафік - той же протокол, що використовується у відеодзвінках, і блокувати його цілком означало б заблокувати значну частину легітимних відеосервісів. Додаткова перевага – немає постійної інфраструктури, яку можна методично заблокувати, бо пул добровольчих вузлів постійно змінюється.

Чому важливо комбінувати, а не вибирати один інструмент назавжди

Практичний висновок, який мені здається недооціненим — цензурні системи теж розвиваються та адаптуються, особливо в країнах із серйозними ресурсами на це завдання (Китай із його Great Firewall — найпросунутіший приклад). Те, що працювало рік тому, може бути детектовано сьогодні через оновлені моделі машинного навчання, що аналізують тонкі статистичні аномалії трафіку, а не лише явні сигнатури. Тому в реальних умовах активної цензури розумна стратегія мати під рукою кілька pluggable transports одночасно і перемикатися за перших ознак деградації з'єднання, а не закладатися на єдиний метод як постійне рішення.