Encrypted Client Hello и DoH: что периметровые файрволы больше не видят

Двадцать лет сетевые файрволы и прокси опирались на одно незашифрованное поле, чтобы понять, куда идёт зашифрованный трафик: Server Name Indication (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, не знает эту запись по имени, поэтому запрашивайте её по номеру:

$ 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 Platform Status), обычно привязанную к использованию зашифрованного DNS. Многие программы вообще его не используют. Диагностический эндпойнт Cloudflare сообщает, что он получил, а встроенный в macOS curl по-прежнему отправляет имя хоста открытым текстом:

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

Так что реалистичная картина сегодня — смешанная: браузеры всё чаще скрывают имя хоста, многие другие программы — нет, а программное обеспечение, написанное для уклонения от мониторинга, может намеренно выбрать ECH и DoH.

Что теряет периметровый файрвол, а что сохраняет

Честный итог таков: фильтрация по имени хоста на периметре перестаёт работать для трафика с 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.