Протягом тривалого часу мережеві інженери розглядали стиснення даних і криптографічне шифрування як взаємодоповнюючі технології. На магістральних каналах передача трафіку створює регулярні фінансові витрати. Тому зменшення розміру пакетів перед шифруванням симетричними алгоритмами здавалося очевидним інженерним рішенням: воно обіцяло зменшення обсягу даних і скорочення затримок під час фізичного передавання. Класичні протоколи, зокрема OpenVPN, інтегрували алгоритми стиснення (передусім LZO та DEFLATE) безпосередньо у транспортний конвеєр.

Логіка такої архітектури виглядала надійною: сучасні симетричні шифри, такі як AES-256-GCM або ChaCha20-Poly1305, перетворюють байти на псевдовипадковий бінарний потік, що не відрізняється від шуму. Вважалося, що спостерігач, який перехоплює зашифровані пакети на лінії зв'язку, не здатний отримати жодної інформації про вихідний відкритий текст.

Однак у 2018 році дослідник кібербезпеки Ахамед Нафіз спростував це припущення, опублікувавши деталі атаки VORACLE (ідентифікатор CVE-2018-3972, представлений на конференціях Black Hat USA та DEF CON 26). Атака VORACLE довела, що стиснення мережевих даних перед шифруванням створює небезпечний побічний канал (side-channel) на основі довжини пакетів. Аналізуючи коливання розміру зашифрованих пакетів під час руху мережею, сторонній спостерігач може побайтово відновлювати конфіденційні дані — включно із сесійними cookie та токенами автентифікації HTTP — без зламу математичних алгоритмів шифрування.

+-------------------------------------------------------------------------+
|                    МЕХАНІЗМ ПОБІЧНОГО КАНАЛУ В АТАЦІ VORACLE            |
+-------------------------------------------------------------------------+
|                                                                         |
|  Зловмисник впроваджує тестові символи ("Cookie: auth=a...")            |
|  в один потік із секретним токеном жертви ("Cookie: auth=s3cr3t...")    |
|                                                                         |
|            Потік відкритого тексту (Секретний токен + Дані атакуючого)  |
|                                    │                                    |
|                                    ▼                                    |
|                       [ Модуль стиснення LZO / DEFLATE ]                |
|                                    │                                    |
|    - Невірний символ -> Немає збігу байтів -> Розмір пакета ВЕЛИКИЙ     |
|    - Вірний символ   -> Спрацьовує вказівник LZ77 -> Розмір ЗМЕНШУЄТЬСЯ!|
|                                    │                                    |
|                                    ▼                                    |
|                       [ Симетричний шифр AES / ChaCha ]                 |
|                                    │                                    |
|                                    ▼                                    |
|    Зашифрований пакет у мережі (Розмір шифротексту видає ступінь стиску)|
|                                    │                                    |
|    Аналіз зміни довжини пакета -> Відновлення символу секрету!          |
+-------------------------------------------------------------------------+

Теорія інформації та походження витоку

Щоб з'ясувати фізичну природу успіху VORACLE, необхідно проаналізувати математичну основу алгоритмів стиснення без втрат. Загальновживані методи, такі як DEFLATE (стандарт RFC 1951) та LZO, ґрунтуються на двох складових: заміні повторюваних послідовностей за ковзним словником LZ77 і префіксному кодуванні Гаффмана.

В алгоритмі LZ77 кодувальник послідовно сканує вхідний потік байтів у пошуках повторень. Коли фрагмент тексту з'являється вдруге в межах ковзного вікна історії (зазвичай обсягом 32 або 64 КБ), алгоритм замінює його компактним вказівником:

  1. Зсув (Distance): На скільки байтів назад розташований оригінальний фрагмент.
  2. Довжина (Length): Скільки послідовних байтів збігаються.

Якщо в мережевому пакеті двічі трапляється однаковий рядок довжиною 16 байтів, повторне входження замінюється посиланням розміром лише у 2–3 байти. Загальний обсяг стиснених даних зменшується пропорційно до надлишковості відкритого тексту.

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

Потокові шифри (як-от ChaCha20 або режим AES-CTR) формують гаму та накладають її на відкритий текст операцією XOR у співвідношенні 1:1. Вхідний блок розміром 412 байтів перетворюється на 412 байтів шифротексту (плюс тег автентифікації). У блокових шифрах (AES-CBC), попри вирівнювання на межі 16 байтів, зменшення обсягу стиснених даних часто перетинає ці межі, видаючи інформацію про довжину з точністю до 16 байтів.

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

Практичний перебіг атаки VORACLE

Вразливість VORACLE була націлена на з'єднання OpenVPN з увімкненими параметрами стиснення (comp-lzo yes або директивою compress). Сценарій реалізується за моделлю адаптивної атаки з обраним відкритим текстом (adaptive chosen-plaintext attack):

1. Перехоплення каналу зв'язку

Атакуючий займає позицію посередника (on-path) щодо трафіку користувача. Типові сценарії: скомпрометована точка доступу Wi-Fi у громадському місці, вразливий локальний маршрутизатор або аналіз трафіку на рівні провайдера. Оскільки дані спрямовуються у зашифрований тунель VPN, атакуючий спочатку не може безпосередньо прочитати корисне навантаження.

2. Впровадження контрольованого відкритого тексту

Жертву спонукають відкрити вебсторінку, підконтрольну атакуючому, або скрипт впроваджується у незашифрований трафік HTTP. Цей код JavaScript починає циклічно відправляти міждоменні запити до цільової системи (наприклад, корпоративного порталу чи поштового сервісу).

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

3. Спрацьовування оракула стиснення

Операційна система передає сформований запит HTTP віртуальному мережевому адаптеру VPN. Програмне забезпечення тунелю стискає пакет перед подачею на модуль шифрування:

Поєднаний відкритий текст у пакеті:
[GET /api/user?probe=TEST_CHAR HTTP/1.1\r\n]  <-- Контролюється атакуючим
[Cookie: auth_token=7a8b9c0d1e2f3a4b\r\n]     <-- Секретний токен жертви

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

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

4. Побайтове вилучення секрету

Атакуючий фіксує розмір зашифрованих пакетів UDP або TCP, які надходять від пристрою жертви до шлюзу VPN. Помітивши раптове зменшення розміру пакета під час перевірки конкретного символу, зловмисник підтверджує правильність чергового байта.

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

Історичний ланцюг: від CRIME і BREACH до VORACLE

VORACLE є логічним кроком у розвитку атак на побічні канали стиснення даних на різних рівнях мережевого стека:

Назва атаки Рік оприлюднення Рівень мережі Цільовий протокол Головний метод протидії
CRIME (RFC 7540 §10.6) 2012 Транспортний / Сеансовий Стиснення на рівні TLS Повна заборона стиснення TLS у браузерах та на серверах
TIME 2013 Прикладний Стиснення відповідей HTTP Випадковий падінг відповідей, обмеження частоти запитів
BREACH 2013 Прикладний Тіло відповідей HTTP (gzip) Маскування динамічних токенів, ізоляція контекстів
VORACLE (CVE-2018-3972) 2018 Мережевий / Тунельний Тунелі VPN (OpenVPN LZO) Повна відмова від стиснення трафіку в конфігураціях VPN

Після публікації атаки CRIME Юліусом Ріццо та Тхай Зионгом робоча група IETF відреагувала рішуче: стандарт RFC 7540 (HTTP/2) прямо заборонив стиснення в TLS. Будь-який протокол, що поєднує автентифікаційні дані та користувацьке введення в одному контексті стиснення, стає вразливим.

У середовищі розробників VPN тривалий час існувало переконання, що функціонування на мережевому рівні (пакети IP) захищає від проблем рівня застосунків. Проте VORACLE довів протилежне: спільна передача даних різного рівня довіри всередині стисненого тунелю призводить до аналогічних витоків.

Чому WireGuard свідомо відмовився від стиснення даних

Розробник протоколу WireGuard Джейсон Доненфельд із самого початку принципово виключив можливість стиснення корисного навантаження зі специфікації протоколу.

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

Відмова від стиснення у WireGuard зумовлена трьома технічними причинами:

  1. Ліквідація витоків за розміром пакета: Без стиснення розмір відкритого тексту суворо відповідає структурі кадру. Противник не отримує зворотного зв'язку за розміром для реалізації атак.
  2. Безпека пам'яті та детермінізм виконання: Бібліотеки стиснення (zlib, LZO) містять складні скінченні автомати з динамічним виділенням пам'яті, де неодноразово знаходили переповнення буфера. WireGuard обробляє пакети в просторі ядра з фіксованим обсягом пам'яті без динамічних алокацій.
  3. Усунення нестабільності навантаження на процесор: Складність стиснення залежить від ентропії даних. Попередньо зашифрований трафік (відео HTTPS, стиснені файли) не піддається повторному стисненню, змушуючи процесор даремно витрачати такти, що спричиняє коливання затримок за високих навантажень.

Архітектура RiceGuard: повна відсутність стиснення та рівномірний падінг

У сучасних захищених мережах стиснення пакетів розглядається як невиправданий ризик. У сервісі VPNRice мережеве ядро RiceGuard реалізує сувору заборону на стиснення корисного навантаження на клієнтах і серверах.

+-----------------------------------------------------------------------+
|                    БЕЗПЕЧНА ІНКАПСУЛЯЦІЯ В RICEGUARD                  |
+-----------------------------------------------------------------------+
|  [ Початковий IP-пакет користувача ]                                  |
|         │                                                             |
|         ▼                                                             |
|  [ ВІДСУТНІСТЬ СТИСНЕННЯ ]   -> Блокування побічного каналу LZ77      |
|         │                                                             |
|         ▼                                                             |
|  [ Стандартний падінг ]      -> Заокруглення до фіксованих кроків     |
|         │                                                             |
|         ▼                                                             |
|  [ Шифрування ChaCha20-Poly1305 ] -> Автентифіковане шифрування       |
|         │                                                             |
|         ▼                                                             |
|  [ Зовнішня UDP-датаграма ]  -> Рівномірний профіль трафіку в лінії   |
+-----------------------------------------------------------------------+

RiceGuard забезпечує захист завдяки таким технічним заходам:

  • Заборона попереднього стиснення: Повне вилучення алгоритмів стиснення з транспортного ланцюга. Пакети шифруються безпосередньо у своєму вихідному форматі.
  • Стандартизований падінг (Padding): Використання спеціальних полів у структурі кадрів для доповнення коротких службових повідомлень і запитів до фіксованих меж, що перешкоджає аналізу мережевого профілю.
  • Передавання на повній швидкості інтерфейсу: Відсутність ресурсомісткої декомпресії дозволяє тунелю працювати на максимальній швидкості фізичного каналу через гігабітні мережі без затримок у чергах ядра.

Користувачі можуть знайти надійні додатки для комп'ютерів та смартфонів на сторінці завантаження VPN.

Аудит та усунення ризиків у чинній мережевій інфраструктурі

Адміністраторам власних серверів VPN рекомендується провести ревізію налаштувань і вимкнути потенційно небезпечні опції стиснення.

Перевірка файлів конфігурації OpenVPN

Перевірте конфігураційні файли сервера (server.conf) та клієнта (client.ovpn) на наявність таких параметрів:

# НЕБЕЗПЕЧНІ ПАРАМЕТРИ - НЕОБХІДНО ВИЛУЧИТИ:
comp-lzo yes
comp-lzo adaptive
compress lzo
compress deflate

Щоб надійно захистити з'єднання від загрози VORACLE, переведіть налаштування у безпечний режим:

# РЕКОМЕНДОВАНА БЕЗПЕЧНА КОНФІГУРАЦІЯ:
# Для OpenVPN версії 2.4+:
compress migrate
comp-lzo no

# Для OpenVPN версії 2.5 та новіших:
# Повне вимкнення підтримки стиснення:
compress stub-v2

Застосування comp-lzo no гарантує, що розмір пакетів не змінюватиметься залежно від вмісту даних перед шифруванням.

Чекліст для системних адміністраторів

  1. Перехід на нові протоколи: Переводьте інфраструктуру тунелів на архітектури WireGuard або RiceGuard, які не містять коду стиснення за замовчуванням.
  2. Впровадження HTTPS та HSTS: Забезпечте повсюдне використання TLS 1.3 для внутрішніх ресурсів, щоб унеможливити ін'єкцію відкритого тестового тексту.
  3. Контроль проміжного обладнання: Переконайтеся, що контролери SD-WAN або оптимізатори каналів не виконують неконтрольоване стиснення всередині тунелю.

Історія криптографії свідчить, що прагнення до мінімальної оптимізації продуктивності нерідко створює критичні вразливості. Намагання зекономити незначну частку трафіку через стиснення руйнує конфіденційність зашифрованого тунелю. Повна відмова від стиснення пакетів у VPN-з'єднаннях повертає надійний захист переданим даним.