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

> ECH (RFC 9849) приховує справжнє ім’я хоста в рукостисканні TLS, а DoH приховує пошук DNS. Що це позбавляє мережевих брандмауерів, а що ні, і куди змінюється видимість.

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/uk/blog/encrypted-client-hello-ech-doh-blind-perimeter-firewalls

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

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

За допомогою ECH клієнт створює два повідомлення ClientHello. Внутрішній містить справжнє призначення та конфіденційні параметри та зашифрований за допомогою HPKE до відкритого ключа, опублікованого сервером заздалегідь. Зовнішній, надісланий у відкритому вигляді, містить загальнодоступне ім’я, як правило, ім’я зовнішньої частини постачальника, тому спостерігач дізнається лише про те, що клієнт спілкується з цим постачальником ([RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html); [Пояснювач Cloudflare](https://blog.cloudflare.com/encrypted-client-hello/)).

*Що бачить мережевий спостерігач (ілюстрація)*

```text
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](https://www.rfc-editor.org/rfc/rfc9460.html)), чий параметр `ech` містить ECHConfigList. Ми запитали справжню. `dig`, який постачається з macOS, не знає запису за назвою, тому запитайте його за номером:

*Термінал, macOS 26.7, 25 вересня 2026 р*

```console
$ 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](https://chromestatus.com/feature/6196703843581952)), яка зазвичай пов’язана з використанням зашифрованого DNS. Багато програмного забезпечення взагалі не використовують його. Кінцева точка трасування Cloudflare повідомляє про те, що вона отримала, а `curl`, вбудований у macOS, усе ще надсилає ім’я хоста в відкритому вигляді:

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

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

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

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

*На передній частині спільного постачальника IP-адреса призначення часто ідентифікує постачальника, а не сайт.*

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

> **Warning:** Твердження про те, що ECH робить трафік «невідстежуваним» або фільтрацію периметра «застарілою», заходять занадто далеко: IP-адреси, час, обсяги та пристрій все ще видно. Втрачається ім’я хоста, а разом з ним і найпростіший важіль політики.

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

Єдине місце, де ім’я хоста ніколи не приховано, — це машина, яка встановлює з’єднання: програма запитала його за назвою. Ось чому 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 — саме вона підтримує точність цих рішень: каталогізує, які домени є звичайною телеметрією, а які — справжнім сервісом, відстежує країну та мережу за з’єднанням і навчає локальну модель (функцію FireAI Pilot) на реальних шаблонах трафіку — і нічого з цього не покидає ваш Mac.

Ви можете почитати про технічні рішення, що лежать в його основі, або спробувати FireAI протягом 17 днів на сторінці [FireAI від HisnLabs](https://hisnlabs.com/fireai/uk/download).

## Sources

- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html)
- [RFC 9460: SVCB and HTTPS DNS resource records](https://www.rfc-editor.org/rfc/rfc9460.html)
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html)
- [Cloudflare: Good-bye ESNI, hello ECH!](https://blog.cloudflare.com/encrypted-client-hello/)
- [Chrome Platform Status: Encrypted Client Hello](https://chromestatus.com/feature/6196703843581952)