QUIC Header Protection RFC 9001: маскування номерів пакетів і захист від DPI у VPN

Протягом десятиліть протоколи транспортного рівня в мережі Інтернет функціонували в умовах архітектурного компромісу: корисне навантаження шифрувалося прикладними протоколами, проте службові заголовки передавалися відкритим текстом. У класичному протоколі TCP порядкові номери (SEQ), номери підтвердження (ACK), параметри вікна прийому та прапорці стану відкриті для будь-якого проміжного маршрутизатора на маршруті. Навіть при використанні сучасного TLS 1.3 поверх TCP зовнішній заголовок транспорту залишається повністю доступним для спостереження.

Схожа вразливість була притаманна раннім тунелям на базі UDP та DTLS 1.2, де номери пакетів і межі епох ключів залишалися відкритими. Це створювало сприятливі умови для пасивного аналізу трафіку інтернет-провайдерами та системами глибокого аналізу пакетів (DPI), що дозволяло відстежувати користувацькі сесії та надсилати фальшиві пакети розриву з'єднання.

Для усунення цього ризику інженерна група IETF стандартизувала механізм QUIC Header Protection (RFC 9001, розділ 5.4). Шляхом вибірки фрагмента з автентифікованого шифротексту корисного навантаження для генерації криптографічної маски, QUIC повністю приховує номери пакетів і критичні прапорці заголовка перед їх відправкою у фізичний канал зв'язку.

Проблема відкритих заголовків: витоки метаданих від TCP до DTLS

У традиційній мережевій інфраструктурі заголовки транспорту виконують подвійну функцію: вони потрібні кінцевим вузлам і водночас аналізуються проміжними пристроями зі збереженням стану (stateful middleboxes) — шлюзами CGNAT, оптимізаційними проксі (PEP) та брандмауерами DPI для контролю трафіку.

Традиційний фрейм TCP / TLS 1.3 (Відкриті метадані у каналі зв'язку):
[IP-заголовок (20B)] [TCP-заголовок: SEQ, ACK, Вікно, Прапорці (20B)] [Запис TLS: Довжина, Тип] [Шифротекст навантаження]
                       ^ Відкрито для кожного проміжного вузла, провайдера та спостерігача!

Короткий заголовок QUIC 1-RTT із захистом Header Protection (RFC 9001):
[IP-заголовок (20B)] [UDP-заголовок (8B)] [Заголовок QUIC 1 байт (ПІД МАСКОЮ)] [Номер пакета: 1-4B (ЗАШИФРОВАНО)] [Шифротекст + Тег AEAD]
                                            ^ Захищено криптографічною маскою на основі вибірки навантаження!

Наявність відкритих порядкових номерів дозволяє аналізаторам трафіку отримувати важливі метадані без зламу основного шифру корисного навантаження.

Пасивне спостереження та аналіз трафіку за номерами пакетів

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

Оцінка втрат та профілювання каналу: Відстежуючи пропуски у послідовності номерів пакетів, сторонній спостерігач може оцінювати перевантаження черг, затримки обробки та фізичні характеристики з'єднання.
Атаки скидання з'єднання: Знаючи актуальні номери пакетів у поточному вікні, атакуючий може створити підроблені пакети TCP RST або повідомлення помилок ICMP, примусово перериваючи сесію.
Кореляція сесій при зміні мережі: Коли мобільний пристрій перемикається між стільниковою мережею та Wi-Fi, послідовна нумерація пакетів дозволяє пов'язати дві різні IP-адреси з одним пристроєм, нівелюючи приватність геолокації.

Механізм захисту заголовків у RFC 9001 повністю вилучає номери пакетів із зовнішнього мережевого образу протоколу (Wire Image згідно з RFC 8546), перетворюючи потік на рівномірну псевдовипадкову послідовність високої ентропії.

Криптографічна архітектура захисту заголовків у RFC 9001

QUIC ізолює шифрування корисного навантаження від захисту заголовків. Якщо корисне навантаження шифрується алгоритмами AEAD (AES-128-GCM, AES-256-GCM або ChaCha20-Poly1305), то для захисту заголовка генерується окремий ключ захисту заголовків (hp_key).

Під час фази узгодження параметрів TLS 1.3 ключ hp_key створюється незалежно за допомогою функції HKDF-Expand-Label:

hp_key = HKDF-Expand-Label(traffic_secret, "quic hp", "", key_length)

Повна ізоляція ключа hp_key від основного ключа шифрування пакетів та вектора ініціалізації (IV) гарантує, що аналіз маски заголовка не дає математичних переваг для зламу корисного навантаження.

Механізм вибірки з корисного навантаження та генерація маски

Щоб захистити заголовок без збільшення розміру пакета, RFC 9001 використовує вибірку із шифротексту корисного навантаження. Оскільки навантаження зашифроване алгоритмом AEAD, його байти мають високу криптографічну ентропію.

Процедура взяття вибірки чітко стандартизована:

Визначення зміщення вибірки: Вузол визначає позицію поля номера пакета (pn_offset). Вибірка розміром 16 байтів береться із зашифрованого навантаження зі зміщенням рівно на 4 байти після pn_offset:
```
sample_offset = pn_offset + 4
sample = packet[sample_offset .. sample_offset + 16]
```
Фіксоване зміщення у 4 байти гарантує незмінність точки вибірки незалежно від того, займає номер пакета 1, 2, 3 чи 4 байти.
Обчислення криптографічної маски:
- Для наборів шифрів AES (AES-128 та AES-256): 16-байтна вибірка передається до алгоритму AES у режимі Electronic Codebook (ECB) з ключем hp_key:
```
mask = AES-ECB(hp_key, sample)
```
  Перші 5 байтів виходу (mask[0..4]) слугують гамою для маскування.
- Для наборів шифрів ChaCha20: Перші 4 байти вибірки інтерпретуються як 32-бітний лічильник блоків (little-endian), а решта 12 байтів слугують nonce. Алгоритм ChaCha20 генерує 5 байтів гами:
```
counter = sample[0..3]
nonce   = sample[4..15]
mask    = ChaCha20(hp_key, counter, nonce, 5)
```

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

Застосування маски: приховування прапорців і номерів пакетів

Після формування 5-байтної маски відправник накладає її на перший байт заголовка та на поле номера пакета за допомогою побітової операції XOR.

Маскування першого байта короткого заголовка (Short Header):
Початковий байт: [ 0 | 1 | S | R | R | K | P | P ]
Байт маски 0:    [ x | x | x | 0 | 0 | 1 | 1 | 1 ] & 0x1f
Результат:       Формат заголовка (0) та Fixed Bit (1) залишаються для маршрутизації,
                 а резервні біти (R), фаза ключа (K) та довжина PN (P) НАДІЙНО ЗАМАСКОВАНІ!

Маскування поля номера пакета (довжина від 1 до 4 байтів):
Початковий PN:   [ Байт 0 ] [ Байт 1 ] [ Байт 2 ] [ Байт 3 ]
Байти маски:     [ Маска 1] [ Маска 2] [ Маска 3] [ Маска 4]
Результат:       Непроникний псевдовипадковий потік номерів у мережі!

/* Псевдокод: накладання Header Protection згідно з RFC 9001 */
void apply_quic_header_protection(uint8_t *packet, size_t pn_offset, 
                                  size_t pn_len, const uint8_t *hp_key, int is_short_header)
{
    uint8_t sample[16];
    uint8_t mask[16];
    
    /* 1. Вилучення 16-байтної вибірки із шифротексту навантаження */
    memcpy(sample, packet + pn_offset + 4, 16);
    
    /* 2. Обчислення 16-байтного блоку AES-ECB за допомогою ключа hp_key */
    aes_ecb_encrypt(hp_key, sample, mask);
    
    /* 3. Накладання маски на молодші біти першого байта */
    if (is_short_header) {
        packet[0] ^= (mask[0] & 0x1f);  /* Короткий заголовок: маскуємо резерв, фазу та довжину PN */
    } else {
        packet[0] ^= (mask[0] & 0x0f);  /* Довгий заголовок: маскуємо резерв та довжину PN */
    }
    
    /* 4. Накладання маски на поле номера пакета (від 1 до 4 байтів) */
    for (size_t i = 0; i < pn_len; i++) {
        packet[pn_offset + i] ^= mask[1 + i];
    }
}

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

Захист від закостеніння проміжних вузлів (Middlebox Ossification)

Закостеніння протоколів виникає тоді, коли проміжне мережеве обладнання виробляє жорстку залежність від відкритих полів заголовків. У середовищі TCP багато брандмауерів блокують пакети з новими опціями або зміненими структурами встановлення зв'язку.

Стандарт RFC 8546 підкреслює: будь-яке відкрите поле в мережі зрештою стає фактором закостеніння. Захист заголовків у QUIC усуває цю проблему:

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

Архітектурна реалізація в RiceGuard та Core L3 VPN

Традиційні рішення VPN нерідко розкривають структуру тунелю через передбачуване лінійне зростання номерів пакетів у зовнішніх датаграмах, що полегшує їх класифікацію системами DPI. VPNRice використовує передовий підхід:

Маскування заголовків на основі вибірки в RiceGuard: Протокол RiceGuard застосовує маскування службових полів зовнішніх UDP-датаграм. Мережеві аналізатори бачать лише однорідний високоентропійний потік, що зводить нанівець спроби статистичної класифікації.
Захист від кореляції сесій у Core L3 VPN: Завдяки маскуванню номерів пакетів мобільні пристрої при перемиканні між стільниковими вишками та Wi-Fi не дозволяють зовнішнім спостерігачам пов'язувати послідовні мережеві сесії.
Апаратна оптимізація на рівні ядра операційної системи: Використовуючи інструкції AES-NI та ARM Cryptography Extensions, VPNRice виконує маскування та демаскування заголовків без затримок у реальному часі.

Підсумок: побудова непроникних мережевих тунелів без витоків метаданих

Механізм захисту заголовків QUIC Header Protection (RFC 9001) започатковує новий стандарт для надійної мережевої інженерії. Доказ того, що службові метадані можна захистити без втрати швидкодії, закріплює пріоритет конфіденційності в мережевих протоколах.

Приховування номерів пакетів забезпечує захист від пасивного стеження, сигнатурного аналізу систем DPI та структурного закостеніння мережевих каналів. Оцініть надійне та конфіденційне підключення до мережі на всіх ваших пристроях разом із Завантажити VPNRice.\n