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 typerecord 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 попросту
вроде завезли, но неполностью
на windows server 2022 настройки уже есть в settings, но он на более новом билде, чем последняя 10
и не будет, и никто не обещал, это уже мертвая ось
эта статья ошибочная, нет и не будет в 10, там за пример взято было построение переходное до анонса 11
Возможно, немного оффтопик, но совсем немного. Может кто пояснить, вот если сайт открывается через ECH, и я хочу внести его в исключения своего VPN, ну просто чтобы быстрее работало, какой домен надо внести в исключения, самого сайта или cloudflare-ech.com? Читал-читал про ECH, но так и не понял. Ведь если SNI зашифровано ещё в браузере, мой VPN же не сможет его распознать и пустить напрямую? Простите, если глупый вопрос.
Написал и догадался как проверить, поэкспериментировал на https://encryptedsni.com/cdn-cgi/trace, результат - исключение целевого домена не влияет, а какой там фронт-домен я не понял…
The flag in the control panel just controls the DNS record. Since the ECH key is the same for all the domains, you can still connect to any (?) domain even if it has ECH disabled.
$ dig +short HTTPS gdeposylka.ru
1 . alpn="h3,h2" ipv4hint=104.25.106.6,104.25.107.6,172.67.80.113 ipv6hint=2606:4700:20::6819:6a06,2606:4700:20::6819:6b06,2606:4700:20::ac43:5071
$ (echo -e "GET / HTTP/1.0\r\nHost: gdeposylka.ru\r\n\r\n"; sleep 10) | ./openssl s_client -CApath /etc/ssl/certs/ -no_ssl3 -no_tls1 -no_tls1_1 -no_tls1_2 -connect gdeposylka.ru:443 -servername gdeposylka.ru -ech_config_list 'AEX+DQBBVgAgACC91NEyBX4eLKQ/XSZk9DabQ/MbtpGNoDC3hOhS7QPtNQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=' -ech_alpn_outer outer,public,h2 -alpn inner,secret,http/1.1
Setting new_session_cb
Connecting to 2606:4700:20::6819:6a06
CONNECTED(00000003)
ECH client callback printing:
SSL_ech_print
s=0x560765ac9410
ech_attempted=1
ech_attempted_type=0xfe0d
ech_atttempted_cid=0x56
ech_done=1
ech_grease=0
HRR=0
ech_returned=0x0
ech_returned_len=0
ech_backend=0
ech_success=1
1 ECHConfig value loaded
cfg(0): [fe0d,56,cloudflare-ech.com,0020,[0001,0001],bdd4d132057e1e2ca43f5d2664f4369b43f31bb6918da030b784e852ed03ed35,00,00]
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R4
verify return:1
depth=1 C=US, O=Google Trust Services, CN=WE1
verify return:1
depth=0 CN=gdeposylka.ru
verify return:1
…
Just linking a related bug report I happened to find today. It says that Cloudflare servers detect the use of Warp, and for some reason refuse to serve ECH to Warp clients.
I downloaded and tested with WARP running in regular (non-socks) mode. Cloudflare’s output indicates no use of ECH but they detect use of WARP. Testing with a different ECH site (https://defo.ie/ech-check.php) indicates ECH succeeds. Testing with Chrome confirms the same behaviour as Firefox with Cloudflare disabling ECH when WARP is used but ECH with other sites working through WARP.
This looks like a deliberate policy decision by Cloudflare, everything is working correctly in Firefox and Chrome.