Блог з безпеки FireAI

Автор FireAI Security & Research Team · Опубліковано

Зашифрований клієнт Hello та DoH: що брандмауери периметра більше не бачать

Зашифрований клієнт Hello та DoH: що брандмауери периметра більше не бачать

Протягом двадцяти років мережеві брандмауери та проксі-сервери спиралися на одне незашифроване поле, щоб знати, куди йде зашифрований трафік: індикація імені сервера (SNI), ім’я хоста, яке клієнт оголошує в першому повідомленні рукостискання TLS. DNS через HTTPS (DoH, RFC 8484) уже приховав пошук DNS, який передує з’єднанню. Encrypted Client Hello, тепер опублікований як RFC 9849, приховує сам SNI. Разом вони видаляють два сигнали, на яких побудовано більшість вихідних фільтрів.

Як працює ECH: внутрішній і зовнішній ClientHello

За допомогою ECH клієнт створює два повідомлення ClientHello. Внутрішній містить справжнє призначення та конфіденційні параметри та зашифрований за допомогою HPKE до відкритого ключа, опублікованого сервером заздалегідь. Зовнішній, надісланий у відкритому вигляді, містить загальнодоступне ім’я, як правило, ім’я зовнішньої частини постачальника, тому спостерігач дізнається лише про те, що клієнт спілкується з цим постачальником (RFC 9849; Пояснювач Cloudflare).

Що бачить мережевий спостерігач (ілюстрація)
TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

Звідки надходить ключ: DNS-запис HTTPS

Клієнту потрібен відкритий ключ ECH сервера перед рукостисканням. Він отримує його від DNS у записі ресурсу HTTPS (тип 65, RFC 9460), чий параметр ech містить ECHConfigList. Ми запитали справжню. dig, який постачається з macOS, не знає запису за назвою, тому запитайте його за номером:

Термінал, macOS 26.7, 25 вересня 2026 р
dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

Якщо цей DNS-запит передається через DoH, мережевий спостерігач не бачить ні пошуку, ні, за допомогою ECH, імені хоста в рукостисканні. Саме про це поєднання йдеться в цій статті.

Чи використовується ECH, залежить від клієнта

ECH — це не те, що вмикає мережа; кожен клієнт сам вирішує. Браузери мають підтримку (Статус платформи Chrome), яка зазвичай пов’язана з використанням зашифрованого DNS. Багато програмного забезпечення взагалі не використовують його. Кінцева точка трасування Cloudflare повідомляє про те, що вона отримала, а curl, вбудований у macOS, усе ще надсилає ім’я хоста в відкритому вигляді:

Terminal
curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

Таким чином, реалістична картина сьогодні є сумішшю: браузери все частіше приховують ім’я хоста, багато інших програм цього не роблять, а програмне забезпечення, написане для ухилення від моніторингу, може навмисно використовувати ECH і DoH.

Що брандмауер периметра втрачає, а що зберігає

На передній частині спільного постачальника IP-адреса призначення часто ідентифікує постачальника, а не сайт.
СигналЗвичайний TLS + DNSECH + DoH
DNS-пошук (яке ім'я)Видно на порту 53Прихований всередині HTTPS для розпізнавача
SNI (яке ім'я хоста)ВидноЛише спільна публічна назва
IP і порт призначенняВидноВсе ще видно
Який пристрій в локальній мережіВидноВсе ще видно
Яка програма на пристроїНе видноНе видно

Чесним підсумком є ​​те, що фільтрація на основі імені хоста на межі перестає працювати для трафіку ECH, тоді як керування на основі IP – ні. Мережа все ще може відмовляти у з’єднанні з відомими розв’язувачами DoH, що на практиці також утримує браузери від отримання ключів ECH через зашифрований DNS, і все ще може блокувати діапазони адрес. Чого він більше не може зробити, так це розрізнити два сайти за одним провайдером або дозволити один і заблокувати інший, не порушуючи TLS у спосіб, який розроблено ECH.

Видимість рухається до кінцевої точки

Єдине місце, де ім’я хоста ніколи не приховано, — це машина, яка встановлює з’єднання: програма запитала його за назвою. Ось чому ECH зміщує вихідний контроль до кінцевої точки. Брандмауеру на основі хоста взагалі не потрібно читати рукостискання; він бачить, який процес відкрив з'єднання, з якою адресою і, коли програма розпізнала ім'я, яке ім'я, перш ніж будь-які зашифровані байти залишаться. Він також бачить одну річ, яку ніколи не міг мережевий пристрій, навіть до ECH: яка програма на машині розмовляє.

  • Вирішуйте для програми, а не для імені хоста: браузер, клієнт синхронізації та невідомий двійковий файл мають різні правила.
  • Розглядайте програму, яка запускає власний DoH, через резолвер, який система не налаштувала, як сигнал, на який варто звернути увагу.
  • Зберігайте списки блокування на основі IP на краю; вони все ще працюють і нічого не коштують.

Яке місце тут посідають FireAI та HisnLabs

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI — це власний продукт HisnLabs: ШІ-фаєрвол, який працює безпосередньо на вашому Mac. Він показує простою мовою кожне з’єднання, яке встановлюють ваші застосунки, і дає вам вирішувати, що покидає ваш Mac, — його ШІ працює локально, тож ваш трафік ніколи не надсилається ні нам, ні будь-кому іншому. Команда дослідників безпеки HisnLabs — саме вона підтримує точність цих рішень: каталогізує, які домени є звичайною телеметрією, а які — справжнім сервісом, відстежує країну та мережу за з’єднанням і навчає локальну модель (функцію Autopilot) на реальних шаблонах трафіку — і нічого з цього не покидає ваш Mac.

Ви можете почитати про технічні рішення, що лежать в його основі, або спробувати FireAI протягом 17 днів на сторінці FireAI від HisnLabs.

Джерела