Encrypted ClientHello (ECH) is now enabled on Cloudflare

Just discovered that Rutracker opens without any circumvention methods on Edge and Firefox, and that turns out to be thanks to ECH, it’s hosted behind Cloudflare.

Note: most browsers require DNS-over-HTTPS to be configured to receive DNS HTTPS type record which contain ECH configuration, however in Firefox 130, it works even with the regular unprotected DNS.

As far as I could find, it haven’t been announced anywhere, except in their documentation:

Caution

ECH is disabled globally, and cannot currently be enabled in the Cloudflare Dashboard.

Starting in August, 2024, ECH will be gradually released on free zones. It will not be possible to disable it. A toggle will be added to the Cloudflare Dashboard at a later point before ECH is made available for other zone plans.

Cloudflare uses a single ECH key & configuration for all the domains

$ dig +short rutracker.org HTTPS
1 . alpn="h3,h2" ipv4hint=104.21.32.39,172.67.182.196 ech=AEX+DQBBYQAgACB/ZNpruUIOMT7U9iv5DLgTo+oHQ7RI7GeHwd0tbccrCAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3031::6815:2027,2606:4700:3034::a
c43:b6c4

$ dig +short crypto.cloudflare.com HTTPS
1 . alpn="http/1.1,h2" ipv4hint=162.159.137.85,162.159.138.85 ech=AEX+DQBBYQAgACB/ZNpruUIOMT7U9iv5DLgTo+oHQ7RI7GeHwd0tbccrCAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:7::a29f:8955,2606:4700:7:
:a29f:8a55
SvcParam: ech
    SvcParamKey: ech (5)
    SvcParamValue length: 71
    ECHConfigList length: 69
    ECHConfig: id=97 cloudflare-ech.com
        Version: 0xfe0d
        Length: 65
        HKPE Key Config
            Config Id: 97
            KEM Id: DHKEM(X25519, HKDF-SHA256) (32)
            Public Key length: 32
            Public Key: 7f64da6bb9420e313ed4f62bf90cb813a3ea0743b448ec6787c1dd2d6dc72b08
            Cipher Suites length: 4
            Cipher Suites (1 suite)
        Maximum Name Length: 0
        Public Name length: 18
        Public Name: cloudflare-ech.com
        Extensions length: 0

cloudflare-ech.com is used as a canary domain (SNI) for TLS requests

Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 587
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 583
            Version: TLS 1.2 (0x0303)
            Random: cb6244609a92947f8ccf9c7e731dc013cf00f739468bad266be3e9d4b40dfea4
            Session ID Length: 32
            Session ID: 2587cb2bc557eb6af6c561df526f2f42111108418712bfe550331cf0a4b1af53
            Cipher Suites Length: 34
            Cipher Suites (17 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 476
            Extension: server_name (len=23) name=cloudflare-ech.com
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: supported_groups (len=14)
            Extension: ec_point_formats (len=2)
            Extension: application_layer_protocol_negotiation (len=14)
            Extension: status_request (len=5)
            Extension: delegated_credentials (len=10)
            Extension: key_share (len=107) x25519, secp256r1
            Extension: supported_versions (len=5) TLS 1.3, TLS 1.2
            Extension: signature_algorithms (len=24)
            Extension: record_size_limit (len=2)
            Extension: encrypted_client_hello (len=217)
                Type: encrypted_client_hello (65037)
                Length: 217
                Client Hello type: Outer Client Hello (0)
                Cipher Suite: HKDF-SHA256/AES-128-GCM
                    KDF Id: HKDF-SHA256 (1)
                    AEAD Id: AES-128-GCM (1)
                Config Id: 97
                Enc length: 32
                Enc: 08181d7e3ce624682fe03c8c31698f5a6c198aff850bccfedf6780e8dea6267e
                Payload length: 175
                Payload [truncated]: 20d54aebde0806f5ea62f287b713d9dba7e93636885160b2588633befe1e986046991c997bf9bd3e96927d99a3a3c0075870644ed6b9d0cd25e8da2ca197ee00907eef3955a5507b83bddecff3a720ad62ff577ac2b685ede87ae196c75e5f4c5ed02566350834bbc945b5f380
            [JA4: t13d1713h2_5b57614c22b0_748f4c70de1c]
            [JA4_r: t13d1713h2_002f,0035,009c,009d,1301,1302,1303,c009,c00a,c013,c014,c02b,c02c,c02f,c030,cca8,cca9_0005,000a,000b,000d,0017,001c,0022,002b,0033,fe0d,ff01_0403,0503,0603,0804,0805,0806,0401,0501,0601,0203,0201]
            [JA3 Fullstring: 771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53,0-23-65281-10-11-16-5-34-51-43-13-28-65037,29-23-24-25-256-257,0]
            [JA3: ed3d2cb3d86125377f5a4d48e431af48]

Да, у меня под йотой rutracker открывается в Brave 1.59.117/Chromium 118.0.5993.70 (sni cloudflare-ech.com) с включенным #encrypted-client-hello (я слышал, что в новых версиях флаг исчез, значит что этот параметр стал по умолчанию и не отключить?)
Напомню, что у меня есть сборка curl для линукса с поддержкой ECH (а также QUIC Quiche). Она тоже работает:
curl --http3-only --ech hard --tlsv1.3 --doh-url https://cloudflare-dns.com/dns-query -v https://rutracker.org/
Что интересно, под warp vpn не хочет: weird server reply.

So cloudflare finally did something good for once? Instead of giving constant 403s to users or thinking you’re bot in neverending verification loop

Видимо cloudflare-ech.com в скором времени окажется в блоке у ркн. Что плохо, потому что тогда может накрыться vless-over-cdn, вырубить-то эту штуку в панели CF пока нельзя.

С ним то что будет? ECH в xray поддержки нет, в sing-box вручную включать надо

С одной стороны, давно этого ждал, особенно в контексте рутрекера.

С другой - риск блокировки Cloudflare или их ECH канарейки очень вырос. Что хуже, на бесплатных тарифах ECH сейчас нельзя отключить - так что если вдруг РКН начнёт фильтровать этот конкретный вариант SNI, заблокироваными окажутся все кто не находится на платном тире, неважно, есть ли они в банлисте\на ТСПУ или нет.

У ркн давно был план по этого поводу. НСДИ и серты минцифры вшитые в новое железо которые нельзя удалить

Я про яблоко, вы мне про макароны.

НСДИ и сертификаты Минцифры тут вообще никаким боком, это отдельная история - та, в которой интернета в РФ не осталось, а остался только интранет с тонким ручейком наружу а-ля ДНРК.

Плохая новость…
Значит в ближайщее время начнут гасить DOH. А у меня провайдер подменят ответы от DNS по udp. Например ссылки youtu.be не открываются. Всё на уровне OS резолвит через dnscrypt-proxy по DOH. Ибо так, и безопаснее, и нет подмены, и даже быстрее ,чем у провайдера по днс бенчмарку. Сейчас они мне сломаются всё. И что тогда делать-то, в прокси резолв всей системы пускать? Это в свою очередь сломает доступ к некоторым сервисам, которые для разных регионов отдают разные IP. Т.е. я буду получать IP для нидерландов через проксю, а соединяться буду из РФ. И сервер будет не отвечать.

Ну а про блокировку ресурсов на CF уже выше написали.

Для ech нужен doh, а если позированые сертификаты будут вшиваться на роутерах у абонентов, то ркн не нужно будет пытаться плясать вокруг collateral damage с блокировками клаудфлер. В этом и была вся суть национального mitm

В хостс записывать. Сейчас неплохо посмотреть как китай это будет делать и как ситуация будет развиваться. Тут могут вполне реально начаться блоки по ип, в том чисте и в китае

Для ECH DoH в случае с Firefox необязателен - см. первый пост в нитке. Персонально я так и пользуюсь им, кстати - у меня есть полностью доверенный DNS в моём интранете, ходящий в DoH\DoT апстримы не принадлежащие Google, Cloudflare и другим бигтехам.

У хромого всё немного хуже, но судя по багтрекеру того же Cromite (форк умершего пару лет Bromite, который был Android-only; Cromite доступен на почти всех платформах) там тоже думают о том чтоб доверять резолвам локального plaintext DNS, если он сообщает в ответ корректные HTTPS-записи.

Завалить DoH не завалив HTTPS в целом тоже будет крайне проблемно. Да, можно будет прибить резолверы Google, Cloudflare, Quad9 и кого-то ещё - однако существует ещё туева хуча других, менее попсово-ширпотребных сервисов, который держат мелкие конторы, шифропанк-коллективы и просто отдельно взятые люди.

вы уверены что ртрекер заблокирован? тот которая 1 ссылка в поисковике открывается, edge
я проверял на их сайте, Cloudflare Browser Check
Secure SNI показывает не включен

Да, заблокирован

На linux - да, на винде - нет.
chrome (srware iron) последние с каких-то версий и на винде, и на linux
На виндовом фоксе четкая зависимость от about:config trr. 0 - нет, 3 - да

Проверял по https://tls-ech.dev/

Клоудфларе запускаются и без обхода блокировок

Да, включили всем на free tier. Обещали вернуть тоггл после того, как выкатят всё в прод для платных пользователей.

Там есть два флага, network.dns.native_https_query и network.dns.native_https_query_win10. Начиная со 130-го фокса оба должны быть по умолчанию включены - тогда работает без DoH с любым DNS, который умеет в HTTPS-записи.

Все тесты я делал на Windows.

Starting in August, 2024, ECH will be gradually released on free zones.

It seems that paid zones can use ECHConfig of free zones.

printf 'GET / HTTP/1.1\r\nHost: readthedocs.org\r\n\r\n' | openssl s_client -tls1_3 -ech_config_list xxxx -alpn 'http/1.1' -connect readthedocs.org:443 -quiet

выяснено, что на виндовс fox использует DNS API, чтобы понять прописан ли в системе DoH
и работает это из коробки только на win11
на win10 - нет

если fox не детектит или не хочет детектить DoH в системе, он требует локальный DoH от себя.
если DoH нет нигде - он отказывается от ECH

пишут, что на win10 детект отключен из-за какого-то бага в винде

на linux нет возможности обнаружить прослойку DoH универсальным образом, потому ECH включают всегда

На 10ой майки на релизную сборку так и не завезли DoH попросту