Протягом багатьох років протокол безпеки транспортного рівня Transport Layer Security (TLS) забезпечував надійний криптографічний захист інформації в глобальній мережі. Щоразу, коли ви відкриваєте вебресурс через захищене з'єднання HTTPS, протокол гарантує шифрування трафіку, запобігаючи перехопленню паролів, конфіденційних форм чи сесійних ключів зловмисниками в локальній мережі. Проте, незважаючи на впровадження стандарту TLS 1.3, на початку кожної сесії зберігалася вразливість: передача ідентифікатора сервера Server Name Indication (SNI) у відкритому текстовому вигляді.

Розробка стандарту Encrypted Client Hello (ECH) у межах робочої групи IETF успішно вирішує цю фундаментальну проблему. Завдяки шифруванню справжньої назви сервера вже на етапі первинного рукостискання, ECH докорінно трансформує взаємодію між веббраузерами, мережами доставки контенту (CDN), хмарними провайдерами та транзитними мережевими шлюзами.

Історична проблема відкритого поля SNI

Щоб оцінити практичне значення ECH, варто пригадати технологію спільного розміщення вебсайтів на одному серверному обладнанні. На початкових етапах розвитку мережі кожному захищеному сайту була потрібна окрема адреса IPv4, адже сервер мав надати відповідний цифровий сертифікат до моменту розшифрування запиту HTTP. З вичерпанням вільного пулу адрес IPv4 розширення SNI було стандартизовано в документі RFC 3546.

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

  1. Відкритість метаданих: Доменне ім'я сайту передається через локальні маршрутизатори Wi-Fi, сервери інтернет-провайдерів і магістральні канали у відкритому текстовому форматі.
  2. Аналіз профілю користувача: Системи глибокої інспекції пакетів (DPI) фіксують незахищене поле SNI для формування журналів активності користувачів або вибіркового зниження пропускної здатності окремих з'єднань.
  3. Неповний захист навіть із шифрованим DNS: Навіть у разі використання захищеного протоколу DNS over HTTPS спостерігачі в мережі можуть легко ідентифікувати ресурси, які ви переглядаєте, зчитуючи дані з першого пакета ClientHello.

Архітектурний механізм функціонування Encrypted Client Hello

Encrypted Client Hello усуває цей ризик шляхом розділення початкового повідомлення на дві структури: зовнішню оболонку ClientHelloOuter та внутрішній блок ClientHelloInner.

1. Отримання публічних ключів через сучасні записи DNS

Перш ніж надіслати зашифровані дані серверу, до якого клієнт звертається вперше, браузеру необхідно отримати відкритий ключ цього сервера. ECH вирішує це завдання через нові типи записів HTTPS або SVCB у системі доменних імен (згідно зі стандартом RFC 9460).

Коли браузер виконує запит адреси домену, авторитетний сервер DNS надає не лише IP-адресу, але й інформаційний пакет echconfig. Цей блок містить відкритий ключ цільового шлюзу та перелік підтримуваних криптографічних алгоритмів стандарту HPKE (Hybrid Public Key Encryption).

2. Подвійна структура рукостискання

Отримавши відкритий ключ, браузер формує дві пов'язані структури:

  • ClientHelloOuter: Загальнодоступний пакет, який бачать усі проміжні мережеві вузли. Він містить стандартні технічні параметри та нейтральне ім'я загальнодоступного шлюзу (наприклад, домен CDN-провайдера), гарантуючи сумісність із традиційним мережевим обладнанням.
  • ClientHelloInner: Справжнє повідомлення з реальною назвою запитуваного домену, повністю зашифроване за допомогою відкритого ключа за схемою HPKE.

Клієнт додає зашифрований внутрішній блок як спеціальне розширення всередину зовнішнього пакета. Приймальний шлюз розшифровує його своїм приватним ключем, передає запит потрібній програмі та успішно встановлює з'єднання TLS 1.3. Для будь-яких проміжних спостерігачів на лінії передачі видно лише загальну назву сервісу CDN.

Порівняння безпекових характеристик протоколів TLS

Параметр безпеки Звичайний TLS 1.2 Стандартний TLS 1.3 TLS 1.3 із підтримкою ECH
Шифрування даних користувача Надійний захист AES/ChaCha20 Сучасні криптографічні алгоритми Сучасні криптографічні алгоритми
Шифрування сертифіката Передається відкритим текстом Зашифровано всередині сесії Зашифровано всередині сесії
Захист назви домену (SNI) Відкритий текст для всіх вузлів Відкритий текст для всіх вузлів Повністю зашифровано через HPKE
Ризик аналізу системами DPI Дуже високий через відкритий SNI Дуже високий через відкритий SNI Мінімальний; видно лише домен CDN
Вимоги до інфраструктури DNS Традиційний незахищений DNS Звичайний DNS або DoH Вимагає використання DoH із записами SVCB

Взаємодія між ECH та захищеним тунелем VPNRice

Хоча Encrypted Client Hello забезпечує високий рівень приватності для веббраузерів, ця технологія не може замінити повноцінне рішення віртуальної приватної мережі для всієї системи.

По-перше, ECH захищає виключно трафік на базі TLS (здебільшого вебсторінки HTTPS). Фонова мережева активність операційної системи, передача даних у комп'ютерних іграх, голосовий зв'язок VoIP та інші програми без підтримки HTTPS продовжують транслювати свої мережеві параметри. По-друге, проміжні вузли все одно бачать IP-адресу призначення. Якщо вебресурс розміщено на окремому виділеному сервері без мережі CDN, його адресу можна легко зіставити з контентом.

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

Щоб дізнатися актуальні параметри вашого інтернет-з'єднання та переконатися у відсутності витоків справжньої адреси, скористайтеся нашим інструментом Дізнатися свою IP-адресу. А для оцінки стійкості браузера під час мультимедійних з'єднань у реальному часі пройдіть Тест на витік через WebRTC.

Завантажити VPNRice.