Протокол захисту транспортного рівня (TLS) становить фундаментальну основу конфіденційності сучасного вебтрафіку, корпоративних з'єднань та захищених тунелів додатків. Під час розробки TLS 1.2 (RFC 5246) та його попередніх версій передбачалося, що поєднання випадкових чисел клієнта й сервера з попереднім майстер-ключем (premaster secret) забезпечує надійне криптографічне розмежування між незалежними мережевими сесіями. Однак на практиці це припущення виявилося вразливим.

У 2014 році фахівці з криптографії оприлюднили атаку «Triple Handshake» — критичну вразливість у TLS 1.0–1.2, яка давала змогу активному посереднику (Man-in-the-Middle, MiTM) синхронізувати майстер-ключі (Master Secret) двох абсолютно різних каналів. Маніпулюючи механізмами повторного узгодження (renegotiation) та відновлення сесій (session resumption), зловмисник міг непомітно зшивати незалежні з'єднання TLS, видаючи себе за авторизованого клієнта або перехоплюючи зашифровані дані. Стандарт RFC 7627 («Transport Layer Security Session Hash and Extended Master Secret Extension») подолав цей недолік архітектури за допомогою розширення Extended Master Secret (EMS), жорстко прив'язавши похідні ключі до повного журналу рукостискання.

Класичний ключ Master Secret у TLS 1.2 (без прив'язки до журналу):
pre_master_secret + ClientHello.random + ServerHello.random ──> PRF ──> master_secret
                └──> У формулі відсутні сертифікати та параметри обміну ключами!

Архітектура RFC 7627 Extended Master Secret (прив'язка через Session Hash):
pre_master_secret + "extended master secret" + session_hash ──> PRF ──> extended_master_secret
                                                     │
               ┌─────────────────────────────────────┴─────────────────────────────────────┐
               ▼                                                                           ▼
[ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, ClientKeyExchange] ──> Хеш-образ сесії
               └──> Математична прив'язка унеможливлює склеювання сесій та підміну MiTM.

Вразливість класичного TLS: відсутність прив'язки до журналу рукостискання

Щоб збагнути важливість розширення Extended Master Secret, варто проаналізувати особливості класичного алгоритму генерації ключів, який уможливлював небажану синхронізацію сесій.

Чому класична генерація Master Secret ігнорує контекст діалогу

У стандартній специфікації TLS 1.2 (розділ 8.1 RFC 5246) після завершення обміну ключами сторони обчислюють 48-байтний ключ master_secret за допомогою псевдовипадкової функції (PRF):

$$\text{master_secret} = \text{PRF}(\text{pre_master_secret}, \text{"master secret"}, \text{ClientHello.random} ,|, \text{ServerHello.random})$$

Ця процедура спирається виключно на три параметри:

  1. Значення pre_master_secret (отримане шляхом асиметричного шифрування RSA або ефемерного обміну Діффі-Геллмана).
  2. 32-байтний псевдовипадковий вектор клієнта ClientHello.random.
  3. 32-байтний псевдовипадковий вектор сервера ServerHello.random.

Ключова проблема полягала в тому, що у формулу генерації не входили реальні повідомлення рукостискання. Алгоритм не враховував ланцюжки сертифікатів X.509 обох сторін, узгоджені набори шифрів та параметри кривих Діффі-Геллмана. Хоча фінальні повідомлення Finished перевіряють цілісність усього діалогу, ця дія виконується вже після остаточного формування майстер-ключа.

Анатомія та сценарій атаки Triple Handshake

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

Схема склеювання сесій в атаці Triple Handshake:
Клієнт                    Зловмисник (MiTM)                    Справжній сервер
  │                               │                                 │
  ├── ClientHello (Random_C) ────►├── ClientHello (Random_C) ──────►│
  │                               │   (Пересилання випадкового числа)│
  │◄── ServerHello (Random_S) ────┼◄── ServerHello (Random_S) ──────┤
  │    Сертифікат (Зловмисника)   │    Сертифікат (Сервера)         │
  │                               │                                 │
  │  [Сесія 1: Клієнт ──► Зловмисник]    [Сесія 2: Зловмисник ──► Сервер]
  │  Обидва канали мають однакові Random_C, Random_S та pre_master_secret!
  │                               │
  ▼                               ▼
В обох сесіях формується абсолютно однаковий Master Secret (MS_1 == MS_2)
  │
  ├── Відновлення сесії / Повторне узгодження із сертифікатом клієнта ───────►
  │   (Зловмисник переносить автентифікацію клієнта у з'єднання з сервером)
  ▼
Зловмисник видає себе за клієнта перед сервером; повна компрометація каналу

Атака здійснювалася у три послідовні фази:

  1. Синхронізація первинного рукостискання: Клієнт ініціює з'єднання з підконтрольним зловмиснику сервером. Одночасно зловмисник відкриває сесію зі справжнім сервером. Дзеркально пересилаючи випадкові вектори та узгоджуючи параметри Діффі-Геллмана, посередник змушує обидва з'єднання згенерувати ідентичний master_secret.
  2. Відновлення сесії: Користуючись механізмом session resumption (через Session ID або Session Ticket RFC 5077), зловмисник відновлює з'єднання зі справжнім сервером на основі збереженого стану.
  3. Склеювання під час повторного узгодження: Коли справжній сервер вимагає двосторонньої автентифікації (mTLS), клієнт підписує перевірочні дані у своєму каналі. Оскільки майстер-ключі збігаються, атакуючий пересилає ці дані справжньому серверу і успішно авторизується від імені довіреного користувача.

Архітектура RFC 7627: криптографічна прив'язка через Session Hash

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

Обчислення Session Hash на етапах обміну ключами

Фундаментальним елементом архітектури є величина session_hash. Вона становить результат хешування всіх повідомлень рукостискання від початкового ClientHello до ClientKeyExchange включно:

$$\text{session_hash} = \text{Hash}(\text{ClientHello} ,|, \text{ServerHello} ,|, \text{Certificate}^* ,|, \text{ServerKeyExchange}^* ,|, \text{ClientKeyExchange})$$

  • У TLS 1.2 алгоритм хешування визначається узгодженою функцією PRF (як правило, SHA-256 або SHA-384).
  • Якщо сервер надсилає ланцюжок сертифікатів X.509, кожен байт даних передається у функцію хешування.
  • Параметри ефемерних кривих ECDHE та супутні цифрові підписи також фіксуються в хеш-образі.

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

Примітив генерації ключів Extended Master Secret

Після узгодження розширення extended_master_secret (тип розширення 0x0017 / 23 у десятковій формі) функція генерації замінює стару мітку та випадкові вектори:

$$\text{extended_master_secret} = \text{PRF}(\text{pre_master_secret}, \text{"extended master secret"}, \text{session_hash})$$

Заміна випадкових векторів на session_hash забезпечує:

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

Захист у циклах відновлення та повторного узгодження сесій

Стандарт RFC 7627 визначає строгі правила переходів станів для запобігання атакам зі зниженням рівня захисту під час відновлення з'єднань.

Матриця станів сесій за стандартом RFC 7627:
Попередній стан сесії  | Запит на відновлення | Рішення вузла        | Результат безпеки
-----------------------+----------------------+----------------------+-----------------------------------------
Класичний Master Secret| Містить прапорець EMS| ВІДМОВА / Новий діалог| Зниження заблоковано; повне узгодження
Extended Master Secret | Без прапорця EMS     | ВІДМОВА / Розірвання | Виявлено втручання; скидання з'єднання
Extended Master Secret | Прапорець EMS валідний| Успішне відновлення | Безпечне зв'язане відновлення сесії
  1. Блокування склеювання сесій та підміни автентичності клієнта: Якщо початкове з'єднання використовувало Extended Master Secret, подальші запити на його відновлення зобов'язані містити розширення EMS. Якщо посередник спробує видалити це розширення з пакетів, приймаюча сторона зафіксує спробу атаки та розірве з'єднання з помилкою handshake_failure.
  2. Зв'язування експортерів ключів (RFC 5705): Сучасні протоколи (WebRTC, EAP-TLS та сервіси тунелювання) застосовують механізм експорту ключів RFC 5705. Стандарт RFC 7627 вимагає, щоб усі вторинні ключі генерувалися на основі Extended Master Secret, що гарантує надійність похідних тунелів.

Еволюція в стандарті TLS 1.3: графи ключів HKDF за повним журналом

Принципи безпеки, закладені в RFC 7627, довели свою ефективність і були безпосередньо інтегровані в ядро стандарту TLS 1.3 (RFC 8446).

У TLS 1.3 класичну схему формування ключів було скасовано на користь багаторівневого розкладу на основі функції HKDF:

Граф генерації ключів у TLS 1.3 на основі повного журналу:
               Ранній ключ (Early Secret / PSK)
                       │
                       ▼
             Ключ рукостискання (ECDHE) ──> HKDF-Expand(Хеш-журналу-1) ──> Ключі діалогу
                       │
                       ▼
              Майстер-ключ ───────────────> HKDF-Expand(Хеш-журналу-2) ──> Ключі даних додатків

На відміну від TLS 1.2, де розширення EMS потребувало явного узгодження, у TLS 1.3 усі ключі природним чином прив'язані до накопичувального хешу повідомлень. Це забезпечує нативний імунітет проти атак класу Triple Handshake за замовчуванням.

Накладні витрати та особливості апаратних криптографічних процесорів

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

Практичні випробування на серверних платформах свідчать, що додаткові витрати ресурсів є несуттєвими:

  • Навантаження на хешування: У типовій сесії TLS сукупний обсяг повідомлень до етапу обміну ключами не перевищує 4 КБ. Обробка 4 КБ алгоритмом SHA-256 триває менше 15 мікросекунд завдяки апаратним інструкціям сучасних процесорів (Intel SHA Extensions або ARMv8 Crypto).
  • Перевага асиметричних обчислень: Понад 98% процесорного часу під час встановлення з'єднання TLS витрачається на операції з відкритими ключами (множення на еліптичних кривих ECDH та перевірку підписів RSA/ECDSA). Частка операцій хешування в EMS становить менше 0,1% від загального часу.
  • Підтримка апаратних прискорювачів: Апаратні модулі безпеки (HSM) та криптографічні підсистеми ядра підтримують потокове оновлення дайджестів без блокування конвеєрів обробки.

Захист корпоративних тунелів: транспортний контур безпеки RiceGuard

У мережевій платформі VPNRice система RiceGuard реалізує вимоги RFC 7627 Extended Master Secret на всіх резервних з'єднаннях TLS, інтерфейсах адміністрування та проксі-каналах.

Архітектура TLS Zero-Trust у RiceGuard:
Клієнтський пристрій / Мобільний додаток
  │  Ініціює сеанс TLS 1.2/1.3 з пограничним вузлом RiceGuard
  ▼
Суворий контроль криптографічних політик
  │  - Обов'язкова наявність розширення EMS (код 0x0017)
  │  - Примусова цілковита пряма таємність (PFS на Curve25519)
  │  - Відхилення застарілих сесій без прив'язки до журналу
  ▼
Безперервний розрахунок Session Hash
  │  - Фіксація сертифікатів та параметрів обміну ECDHE
  │  - Прив'язка експортерів ключів RFC 5705 до хешу сесії
  ▼
Відмовостійкий шлюз RiceGuard
  │  - Повна нейтралізація атак склеювання сесій та підміни MiTM
  │  - Захист взаємної автентифікації mTLS у мережах Zero-Trust
  ▼
Захищений корпоративний периметр / Глобальна шифрована мережа
  1. Обов'язкова політика EMS: RiceGuard впроваджує строгі криптографічні стандарти. У середовищах, де потрібна підтримка TLS 1.2 для сумісності, система відхиляє запити без розширення Extended Master Secret.
  2. Канальна ізоляція токенів: Для процедур ідентифікації Zero-Trust застосовуються вторинні ключі RFC 5705, створені на базі EMS. Це гарантує неможливість повторного використання внутрішніх токенів в інших сесіях.
  3. Надійне кешування сесій: Під час переходу мобільних пристроїв між мережами Wi-Fi та стільникового зв'язку RiceGuard перевіряє квитки відновлення щодо збережених дайджестів, зберігаючи безперервність роботи та криптографічну ізоляцію.

Перевірка та аудит: контроль розширення EMS в OpenSSL та мережевому стеку

Системні адміністратори можуть перевірити функціонування RFC 7627 на діючих серверах за допомогою стандартних утиліт OpenSSL.

Перевірка розширення Extended Master Secret у повідомленнях ClientHello

За допомогою команди openssl s_client можна перевірити, чи підтримує віддалений шлюз розширення EMS:

# Підключення за протоколом TLS 1.2 з виведенням налагоджувальної інформації
openssl s_client -connect vpn.example.com:443 -tls1_2 -tlsextdebug -status

Знайдіть у виведенні повідомлення про стан розширення:

TLS server extension "extended master secret" (id=23), len=0

Нульова довжина поля даних свідчить про те, що сервер успішно узгодив Extended Master Secret відповідно до вимог RFC 7627.

Аудит прапорців узгодження в OpenSSL та сокетах ядра операційної системи

У програмних модулях та сценаріях автоматизованого моніторингу статус прив'язки сесії перевіряється програмним шляхом:

/* Фрагмент коду мовою C для аудиту статусу EMS в OpenSSL */
#include <openssl/ssl.h>

void audit_connection_security(SSL *ssl) {
    if (SSL_get_extms_support(ssl)) {
        printf("RFC 7627 Extended Master Secret: АКТИВНО (Прив'язка до журналу)\n");
    } else {
        printf("УВАГА: Використовується класичний Master Secret! Ризик атаки склеювання.\n");
    }
}

У версіях OpenSSL 1.1.1 та 3.x розширення EMS увімкнено за замовчуванням. Для централізованого контролю системні адміністратори можуть зафіксувати цю вимогу у файлі /etc/ssl/openssl.cnf:

[system_default_sect]
Options = ExtendedMasterSecret

Стандарт RFC 7627 усунув небезпечний розрив між процесом узгодження параметрів та обчисленням сесійних ключів. Прив'язуючи майстер-ключі до повного криптографічного журналу рукостискання, розширення Extended Master Secret гарантує захист корпоративних тунелів від перехоплення та підробки облікових даних.

Щоб розгорнути стійкі тунелі нульової довіри з надійною криптографічною прив'язкою сесій, Завантажити VPNRice.