На данный момент, использование ESNI у многих провайдеров, применяющих DPI, ухудшает доступность сайтов, вопреки ожиданиям.
Причина в отсутствии SNI.
DPI многих провайдеров настроены так, что когда они не могут определить, к какому домену производится доступ, они блокируют соединение, и фактически получается блокировка по IP.

Реестр запрещенных сайтов состоит из следующих элементов:

• Тип блокировки : default (обычно используется для конкретных HTTP URI), domain, ip
• Домен
• IP-адрес/адреса
• Другая нетехническая информация, вроде судебного решения и органа, добавившего элемент в реестр

Пример:
Есть в реестре заблокированный домен w1.mobgo1azino.site, с IP-адресами 104.28.26.13 | 104.28.27.13. Он заблокирован по доменному имени (реестр содержит IP-адреса даже для типа блокировки type=domain).
Вы хотите зайти на незаблокированный сайт bo0om.ru, у которого те же IP-адреса, потому что оба сайта находятся за Cloudflare.
Если вы используете браузер без ESNI, то DPI провайдера увидит, что вы пытаетесь зайти на bo0om.ru по этим IP-адресам, и разрешит соединение.
Если вы будете использовать ESNI, то в TLS ClientHello-пакете не будет поля SNI, и DPI заблокирует ваше соединение.

Ещё стоит отметить, что в России заблокирован стандартный DoH-резолвер, вписанный в Firefox, mozilla.cloudflare-dns.com.
https://isitblockedinrussia.com/?host=mozilla.cloudflare-dns.com

Один адрес, 104.16.249.249, внесён в реестр для домена ineedusersmore.net (многие провайдеры не будут блокировать другие сайты на этом IP-адресе, но не все).
Второй адрес, 104.16.248.249, внесён уже чисто по IP-адресу, на основании «суд;2-946/13», и доступ к нему должен блокироваться полностью.
Не удивляйтесь, если DoH в Firefox будет работать через раз или не работать вовсе.

The date given for the blocking order of 104.16.248.249 is 2013-06-10, over six years ago. It could not have been a DoH server at that time. Perhaps the IP address was used for some other purpose in 2013, and the DoH server inherited the block?

https://isitblockedinrussia.com/?host=mozilla.cloudflare-dns.com

screenshot of https://isitblockedinrussia.com/?host=mozilla.cloudflare-dns.com558×672 33.5 KB

1.1.1.1 is still reported as not blocked. (It’s not the default in Firefox, I believe it would have to be configured manually.)

https://isitblockedinrussia.com/?host=one.one.one.one

screenshot of https://isitblockedinrussia.com/?host=one.one.one.one558×672 19.4 KB

That’s the date of court decision, not the date of the record. The IP addresses were added to the registry in the end of 2016 [1,2].

Oh, and you got inconsistent result from isitblockedinrussia. It’s fully blocked for me.

Screenshot_20190923_214146-fs81116×614 23.4 KB

Please ping the author here: Результаты меняются из раза к разу · Issue #3 · deNULL/isitblockedinrussia.com · GitHub

eSNI это очень плохая идея. Во-первых, сессию очень легко на мидлбоксе свалить в fall back на TLS 1.2. Во-вторых, DoH легко режется по SNI сам по себе, потому что из-за доступности и обратной совместимости большинство провайдеров поддерживают fallback to SNI (мы проверяли в лаборатории). Ну и пробинг, собственно, ловит и позволяет пресечь. Доступность теряется. Требовалось либо обеспечить глобальный переход всех и сразу, и без fallback - что невозможно, либо не заморачиваться вообще.

Как я понимаю, ESNI прежде всего сделан для защиты приватности, чтобы провайдер пассивно не мог анализировать пользовательское поведение на основании DNS-запросов и SNI в TLS, а не для предотвращения цензурирования доступа.

В общем и целом - да. Кроме того, всегда остается опасность подписывания сертификата мидлбокса у рутов, и незаметного подсматривания (peek или stare) доменного имени; ну и реверсивные прокси видят TLS полностью, о чем не стоит забывать.

Такое практически невозможно в современном мире PKI, где используется Certificate Transparency.

Не понял, о чем речь.

Я бы насчет рутов не говорил “невозможно”. Вспомним Симантек и BlueCoat. Которые по сей день находятся в эксплуатации (есть доказательства).

Реверсивные прокси для кэширования полностью расшифровывают HTTPS. Кэшировать без расшифровки HTTPS трафик невозможно. Это мало кто знает - это не афишируется - но это так. Об этом следует помнить.

Они не стоят у провайдера, а если и стоят, то только специализированные, вроде Google Global Cache, который сам управляет всем.
В любом случае, это уже не по теме.

Они именно у провайдера и стоят. Cloudflare стоит прямо на провайдерах во многих случаях. GGC… я не могу это обсуждать, к сожалению. CDN это отдельная, очень нехорошая, тема, которую, к сожалению, считают к делу не относящейся. Просто я бы посоветовал не отмахиваться от этого, окей? Это все, что я могу сказать.

6 posts were merged into an existing topic: Cloudflare blocked IP circumvention

Let’s discuss Cloudflare’s feature in Cloudflare blocked IP circumvention

У домена cloudflare-dns.com, на котором расположен обычный DNS-over-HTTPS-резолвер от Cloudflare, такие же IP-адреса, что и у mozilla.cloudflare-dns.com, а значит, что он также не будет работать корректно в РФ через многих провайдеров.

Мне пишут:

[…] друг использует приложение Simple DNSCrypt с dns от cloudflare (DoH), периодически он просто падает.
[…]Падает не программа, а само соединение к https://cloudflare-dns.com/dns-query и в такой момент только через впн работает.

По каким причинам ESNI может не фунциклировать?

изображение1255×422 100 KB

Для работы esni необходимо также использовать dns-over-https.

Таки он включен, первая галка про это и говорит.

Поддержку ESNI убрали в Firefox 85.

Cloudflare включил поддержку ECH на некоторых доменах. Rutracker работает через ECH в Firefox 130.

Интересно посмотреть, как браузеры будут обрабатывать блокировку cloudflare-ech.com «заморозкой» соединения, как это сейчас реализовано в РФ. Полагаю, что не очень хорошо.

Да, у меня под йотой 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.

https://community.cloudflare.com/t/encrypted-client-hello-ech-are-being-enabled-again/700863/3
медленно выкатывают, у себя пока не решаются

В Chrome 128 тоже работает, отключить нельзя

В хроме начал рутрекер по quic открываться без обходов. Раньше не работал

У меня и без quic сейчас открывается, с ech.

Да, если убрать флаг --http3-only, то ошибка становится
BoringSSL: error:1000013f:SSL routines:OPENSSL_internal:ECH_REJECTED
В браузере работает, но он отказывается от ECH в случае проблем.
Непонятно только как VPN (пусть даже от Cloudflare) может влиять на работоспособность ECH. Разве что там резолвятся какие-то другие IP сайта (который тоже за Cloudflare) без поддержки ECH.

Очень трудно отследить куда идёт warp (из нск), как раз из-за гео оптимизации. Но я вроде докопался, изучал транзитные айпишники из traceroute, у всех одна AS, которая судя по всему в Спб, а дальше Швеция. Cloudflare осталась в РФ работать, да.

И не только rutracker, еще nnmclub и kinozal, они видимо тоже на CF

Похоже все адреса 104.* имеют вероятность тупо работать сейчас. Я уже обнаружил несколько сайтов которые тоже работают, причем так быстро что чувствуется как магия после годов использования проксей где медленная скорость уже привычна.

Непонятны три вещи:

1. откуда браузер знает, что вместо SNI rutracker.org нужно сначала отправить SNI cloudflare-ech.com и только потом rutracker.org ?

2. Браузеры, которые этого не умеют, теперь не смогут ходить на сервера cloudflare или для них оставлена какая-то лазейка?

3. Что будет, если cloudflare-ech.com заблокируют? Будет ли браузер посылять стандартное ClientHello, при невозможности подключиться с использованием ECH?

Я подозреваю, что некоторая лазейка будет оставлена ради совместимости со старыми или экзотическими браузерами. Следовательно блокировка cloudflare-ech.com будет незаметна для пользователей.

Добавление.
Или что будет, если браузеру заблокировать возможность узнавать для какого домена использовать стандартный ClientHello, а для какого - ECH? Ведь наверняка он берет эту информацию где-нибудь в Интеренте.

Кстати, это все можно проверить, заблокировав cloudflare-ech.com локально, а потом попробовать зайти на сервер, который использует ECH. Проверьте кто-нибудь на досуге. Я сам не могу, у меня лапки.

dig https rutracker.org @one.one.one.one
https отвечает за http3/ech/etc

rutracker.org. HTTPS IN 163s 1 .
alpn=“h3,h2”
ipv4hint=“104.21.32.39,172.67.182.196”
ech=“AEX+DQBB8gAgACDCIaU3P6vz668J2oRRZtptSEwH+1IX8/3TOArEx0tRLAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=”
ipv6hint=“2606:4700:3031::6815:2027,2606:4700:3034::ac43:b6c4”

И что эта абракадабра значит?

В двух словах:

0. DNS рассказывает браузеру о том, что сайт поддерживает ECH
1. Предоставляет публичный ключ для шифрования SNI до эндпойнта и сообщает SNI для OuterClientHello
2. Показывает на IP-адреса эндпойнта куда можно стучаться с зашифрованным публичным ключом SNI InnerClientHello
3. Сообщает о поддерживаемых протоколах для итоговой передачи данных

1. кто рассказывает? DNS Cloudflare? Google? А DNS российских провайдеров рассказывают? А если не расскажут?

2. непонятно, почему браузер использует SNI cloudflare-ech.com, ведь ECH по идее может использовать не только Cloudflare.

Я совсем не разбираюсь в этих ваших компуктерах. Но предполагаю, что заблокируют этот ECH и никто этого даже и не заметит (кроме некоторых пользователей этого форума).

The public_name cloudflare-ech.com comes from DNS.

$ echo AEX+DQBB8gAgACDCIaU3P6vz668J2oRRZtptSEwH+1IX8/3TOArEx0tRLAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= | base64 -d | xxd
00000000: 0045 fe0d 0041 f200 2000 20c2 21a5 373f  .E...A.. . .!.7?
00000010: abf3 ebaf 09da 8451 66da 6d48 4c07 fb52  .......Qf.mHL..R
00000020: 17f3 fdd3 380a c4c7 4b51 2c00 0400 0100  ....8...KQ,.....
00000030: 0100 1263 6c6f 7564 666c 6172 652d 6563  ...cloudflare-ec
00000040: 682e 636f 6d00 00                        h.com..

https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-05.html#section-3
https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html#section-4

Different servers may use different public_names. Cloudflare servers will use cloudflare-ech.com, other web hosts will use a different name. The information an observer can get from observing public_name should be roughly the same as what it can get from observing the destination IP address.

It may not be as easy as you think. I have not looked at how things are actually implemented, but TLS clients that support ECH are supposed to send an ECH TLS extension even when they are not using ECH. This is called ECH GREASE. It’s not quite like the situation with ESNI in 2020, when only connections that used ESNI sent the ESNI TLS extension.

6.2.GREASE ECH

If the client attempts to connect to a server and does not have an ECHConfig structure available for the server, it SHOULD send a GREASE [RFC8701] “encrypted_client_hello” extension in the first ClientHello as follows:

так каким способом можно проверить работу ECH в браузере?

https://tls-ech.dev/
https://defo.ie/ech-check.php

не уверен насчет

Любой DNS, который возвращает корректные ответы на запросы HTTPS-записей. Есть эти записи или нет - это зависит от конкретно взятого сайта и его владельца (пользуются ли они ALPN, ECH, проксируются через Cloudflare или нет, etc).

Большинство публичных DNS эту запись возвращают. В этом сообщении показано, как именно пнуть dig, чтобы проверить наличие HTTPS-записи на DNS интересующего вас сайта.

https://crypto.cloudflare.com/cdn-cgi/trace
См. значение “sni” в выхлопе. Если ECH был использован при подключении - будет равен “encrypted”, если нет - “plaintext”

Если нынешний деплой ECH Cloudflare будет заблокирован по SNI cloudflare-ech.com, то есть весьма большая вероятность что станут недоступными сразу все сайты, которые пользуются их бесплатным тарифом (принудительный деплой произошёл именно у фри-юзеров, и отключить ECH там сейчас нельзя).

В переводе: в этом сценарии отвалятся rutracker.org, 2ch.hk, и даже midpass.ru - а vimeo.com останется работать, поскольку они пользуются платным тарифом на котором ECH не был включен принудительно.

как я говорил показывает что не включено
ртрекер открывает, этот сайт, твиттер и т.п. нет
а сам esni тогда теперь по другому называется, но по сути эта тема тоже самое

Firefox 129 - работает
Chrome 129 - нет
Chromium 128 - работает

Открываются Рутрекер, Кинозал, что-то еще.

Есть существенная разница.

В eSNI в принципе не было разделения на InnerClientHello и OuterClientHello - и доступного чистым текстом SNI не было вообще, он всегда был зашифрован. Собственно, об этом говорится даже в самом первом посте этого треда.

Из-за этого провайдерам было проще дропать подобный TLS-трафик, поскольку его пункт назначения было невозможно распознать.

В ECH в свою очередь есть OuterClientHello, в котором есть поле SNI в открытом виде - и провайдер таким образом на своём DPI сможет понять, что трафик идёт скажем куда-то там на Cloudflare.

ну вот не знаю чего ему (cloudflare) у меня не нравится
два других сайта норм. если в about:config что надо включено то пишут “работает”
https://www.cloudflare.com/ru-ru/ssl/encrypted-sni/ ну “через раз”

https://crypto.cloudflare.com/cdn-cgi/trace

115ESR win10, 130 ubuntu

http=http/3 (иногда http/2 при этом .ico всегда по http/3)
tls=TLSv1.3
sni=plaintext
kex=X25519

Этот тест не всегда корректно работает. Я бы рекомендовал опираться на результаты tls-ech.dev

Напомните, у вас флаг network.dns.native_https_query в конфиге файерфокса установлен в true или нет? См. https://groups.google.com/a/mozilla.org/g/dev-platform/c/oh_Tk0iLT9A и 1890999 - Let network.dns.native_https_query ride the trains для контекста.

проверил в chrome и firefox: так и есть, после блокировки sni cloudflare-ech.com перестают открываться все сайты на cloudflare с вкл. ECH, fallback на подключение без ECH нету (и надеюсь не добавят)

в firefox network.dns.native_https_query по дефолту и так true, но HTTPS запросов по UDP DNS нету, есть еще флаг network.dns.native_https_query_win10 который включает HTTPS запросы по UDP DNS (A и AAAA запросы после этого пропадают), но ECH при этом всё равно не работает, приходится включать DoH чтобы ECH заработал

ECH не работает, если VPN от Cloudflare и сайт от Cloudflare. Видимо, друг от друга им нечего скрывать. Можно также посмотреть в Wireshark заголовок SNI (он запрятан глубоко), но в новых версиях можно включить отображение домена не только на основе DNS, но и SNI.

115esr нет такого

130
network.dns.native_https_query true
network.dns.native_https_query_win10 false

p.s. оно просто “выключено” в ДНС
one.one.one.one. 83323 IN HTTPS 1 . alpn=“h3,h2” ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

https://one.one.one.one/cdn-cgi/trace
https://crypto.cloudflare.com/cdn-cgi/trace
sni=plaintext

https://rutracker.org/cdn-cgi/trace
sni=encrypted

Всё правильно, этот флаг появился два месяца назад в 128-129 версии.

а вот как проверка https://www.cloudflare.com/ru-ru/ssl/encrypted-sni/
“находит” SNI я уже не понимаю

www.cloudflare.com. 209 IN HTTPS 1 . alpn=“h3,h2” ipv4hint=104.16.123.96,104.16.124.96 ipv6hint=2606:4700::6810:7b60,2606:4700::6810:7c60

image1084×114 6.22 KB

У меня кстати под первым пунктом Secure DNS стоит вопросик типо мы не могли определить это, во всех остальных галочка. Значит ли это что мой запрос даже кф не мог вычислить, хорошо это или плохо?

CF не может вычислить чужие DoH, только свой в первом пункте показывает как успех.

настройки в браузерах
DoH == cloudflare
в firefox это https://mozilla.cloudflare-dns.com/dns-query

свой он тоже не смог вычислить

Просто.
После нажатия на кнопку, страница в том числе пытается загрузить https://encryptedsni.com/cdn-cgi/trace

meduza.io добавили ECH
Появился новый — очень удобный! — способ читать «Медузу» без VPN. Все необходимое уже есть в вашем браузере Простая инструкция, которая может помочь обмануть Роскомнадзор — Meduza

ValdikSS рассказал им. Ждём блокировку DoH.

Что-то здесь DEfO ECH Domain Name Check ничего не проверяет, страница обновляется, и на ней всё то же.

Ну, через запись в DNS можно посмотреть. И, кстати, посмотрел свой сайт, он на бесплатном тарифе CF, ECH включён, значит, включили для всех клиентов, хотя в настройках нет.

И это также значит, что если начнут блокировать фронт-домен, отвалится треть интернета.

Сделал скрипт для проверки наличия ECH у сайта. Делает запрос к гугл-днс через курл и парсит ответ.

ECH_Support_Tester.cmd (1,5 КБ)

upd: оптимизация

Сайты с поддержкой из тех что я успел почекать:

kinozal.tv
hdkinoteatr.com
gelbooru.com
konachan.com
readmanga.live
checkvpn.net
novayagazeta.ru
annas-archive.org
xhamster2.com
hentaiera.com
10minutemail.net
libgen.li

Сейчас попробую докрутить скрипт и может быть весь russia-blacklist через него прогоню.

Да, не проверяет. Кстати, можно проверить в Wireshark. В фильтр вводите frame contains "forum.ru-board". Если таких пакетов не будет, а сайт открывается, значит ECH и DoH работают. Может появиться какой-нибудь домен Cloudflare, если вы посещаете Cloudflare. Но в таком случае посмотрите на тело пакета или на заголовок Server Name Indication (далеко запрятан). Это наверняка будет фейковый публичный адрес, просто он совпадёт с фильтром, т.к. от одной конторы. А новые версии Wireshark SNI автоматически показывают, если включить в настройках.

Так, я написал прогу которая проверяет все сайты в листе на наличие ECH и выводит результаты в 2 листа (с поддержкой ECH и без). Таким образом, по идее, можно сильно сократить блэклист, т.к. сайты с ECH открываются без обхода. Кто хочет сам попробовать - просто перетаскиваете лист в формате txt на экзешник. Убедитесь что у экзешника есть доступ к сети.

ech_tester.zip (4,2 МБ)

Сейчас я попробую прогнать фул проверку по вот этому списку.

Боюсь ГуглДНС меня возненавидит за 40к запросов.

upd: походу я там накосячил с keep-alive, он очень много соединений оставляет за собой. Щас попробую что-нибудь придумать

upd2: вроде исправил?

И-и-и… готово! На основе вот этого листа (42686 адресов на момент тестирования), я сформировал 2 списка:

• с ECH (20336 адресов):
  domains_all_withECH.txt (346,1 КБ)

• Без ECH (22350 адресов):
  domains_all_withoutECH.txt (400,3 КБ)

Иными словами, 47,6% всех сайтов из данного блеклиста открываются без всяких обходов, на современных браузерах. Это НАМНОГО больше, чем я ожидал. И это число будет только расти. Что РКН собираются с этим делать я хз.

Заставят всех операторов форвардить DNS-запросы со своих рекурсоров на рекурсоры НСДИ. На самих рекурсорах порежут отдачу HTTPS-записи. Так хотя бы по-умолчанию открываться заблоченные сайты не будут. Пользователю нужно будет вручную прописывать какой-нибудь 8.8.8.8, DoH или DoT. Следующим этапом заблочат их.

Ну, будем резолвить через тор, что тут сказать

Да без проблем. Мы же говорим про то, чтобы работало без телодвижений со стороны пользователя.

Без телодвижений со стороны пользователя есть всякие штуки типа ODoH, в лисе уже сейчас поддержка есть. В Waterfox так вообще прям из коробки доступно и работает, на основе мостов fastly. Да и cloudflare заявляли, что они движутся в сторону полностью зашифрованных ДНС запросов. В итоге провайдер даже понять не сможет что это ДНС запрос, т.к. он направлен хз куда и содержимое его хз какое.

Oblivious DNS over HTTPS это для другого. Это чтобы оператор DNS-сервера (например Google со своим 8.8.8.8) не мог установить связку: IP-адреса клиента - какие адреса он резольвит. Что-то вроде этого - About iCloud Private Relay - Apple Support - но только для DoH. Дополнительный уровень приватности. В случае обычного DoH ISP и так уже имен не видит.

Да я читал. Но суть всё равно такова, что запрос то идет не к айпи резолвера, а к айпи oblivious-прокси. Что создает дополнительные сложности для фильтрации трафика. И при этом “без дополнительных телодвижений” со стороны пользователя.

Вон они блокируют-блокируют, а в итоге, всё равно, все кто хотели - доступ имеют. Пока до белых списков дело не дойдет, ничего они не добьются.

Сделал со второго списка себе rule-set для sing-box. Думаю, что можно поставить cicd где-нибудь и пусть каждый день запускает тест + сборку с теста. Можете, пожалуйста, оставить гитхаб чтоб на вас ссылка была, а то я почти ничего не сделал и чтоб была ссылка на вас
UPD: Использование оперативки сократилось с 45 до 8-10 на sing-box. Прям хорошо идет

Для https://ntc.party/ ECH будет включён?

Я больше хочу посмотреть на рожу ркн после того как они профукали 100млд или сколько там на “улучшение” оборудования для теперь устаревшей технологии sni

в китае же как-то забанили ECH, так в чем проблема им тут также сделать? их мне кажется не волнует проблема работы разрешенных сайтов, их цель - сломать и уничтожить

В Китае заблокирован tls 1.3. Поэтому там и не работает ech. Могут ли у нас рискнуть такое сделать? Ну хз-хз…

And just like China, Russia is cracking down on these new technologies. According to the proposed law amendment, any company or website that uses technology to hide its website identifier in encrypted traffic will be banned inside Russia after a one-day warning.

Вот что случится если допустим они захотят оставить сам протокол. Ркн пришлет свою пацанскую предъяву клаудфер, типа за вашим доменом хостятся иноагенты, убирете их с ваших аддресов или мы заблокируем весь аддресс рендж.

Я походу неправильно понял сообщение, но как там может быть заблокирован tls 1.3 когда весь vless reality основан на tls 1.3?

Basically，REALITY 只是改了认证方式的 TLSv1.3，所以，它传输载荷的方式与 TLSv1.3 完全相同，毕竟，REALITY 就是 TLSv1.3
Basically, REALITY is just TLSv1.3 with authentication changed, so it transmits loads in exactly the same way as TLSv1.3 - after all, REALITY is TLSv1.3!

Как вариант, могут блокнуть по SNI адрес “cloudflare-ech.com”, который фигурирует в SNI в запросах, использующих ECH

даже лучше, блокать все подключения у которых заявлена поддержка ESNI, как делают в Китае (Exposing and Circumventing China's Censorship of ESNI)

• The 0xffce extension is necessary to trigger the blocking.
• The blocking can happen on all ports from 1 to 65535.
• Once the GFW blocks a connection, it will continue blocking all traffic associated with the 3-tuples of (srcIP, dstIP, dstPort) for 120 or 180 seconds.

Так как это статья от 2020 года, то ECH тогда ещё был новым и блокировался только ESNI, сейчас возможно уже и его блокирует.

Так ведь тогда большинство сайтов за Cloudflare перестанет работать. И обидных и безобидных. На данный момент те, кто на бесплатном тарифе и те, кто на платном, но включил ECH сам. Разве что им попробовать блокнуть так, чтобы браузер фаллбакнулся в non-ECH, но не уверен, что это возможно. Конструктивно это предусмотрели. Разве что заставить весь народ сидеть на старых браузерах (двух годовой давности), которые ещё не слышали о ECH или Pale Moon.

Насчёт Китая, интересно как там. Но думаю, Cloudflare просто сотрудничает (отключила ECH сама). Ведь они представлены в Китае.

The next strategy we discover can also be used from client or server. In this strategy, the client sends the ESNI request across two TCP segments, such that the first TCP segment is less than or equal to 4 bytes long.

Это обходилось просто сплитом на 4 позиции из самого простого

Перестанет, но только у тех, кто включал DOH в настройках браузера (по умолчанию он вроде отключён), потому одним выстрелом убьют двух зайцев.

Искусственная зависимость ECH от наличия DoH/DoT только в Firefox. В Chrome работает независимо от того, каким образом получена HTTPS-запись из DNS. И кстати да, по RFC fallback не предусмотрен.

Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of this ClientHello, including the SNI.

Все верно, перестанет.

Только на Windows 10? Не 11, не Linux.

Искусственная зависимость ECH от наличия DoH/DoT только в Firefox

Разве?
У меня в Firefox полностью отключен DoH, используется дефолтный системный резолвер, но при этом ECH работает

По поводу Firefox я похоже отстал от жизни. Вот, из changelog:

HTTPS DNS records can now be resolved with the operating system’s DNS resolver on specific platforms (Windows 11, Linux, Android 10+). Previously this required DNS over HTTPS to be enabled. This capability allows the use of HTTP/3 without needing to use the Alt-Svc header, upgrades requests to HTTPS when the DNS record is present, and enables wider use of ECH.

Почему в списке ОС нет Win10 - не понятно.

Там какой-то баг детекта системного DoH.

Я хз. Про то, что в Китае заблочен tls 1.3 читал на реддите. Где здесь правда, где выдумка - утверждать не возьмусь, разбираться тоже лень. Хотя, в Китае же, вроде, используют VMESS, а не VLESS. Первый сам шифрует, второй полагается на шифрование tls. Если я не ошибаюсь. Возможно тут есть связь. Хз.

Блин, только не говорите, что придется на вин11 пересаживаться в скором времени

Win 10 ожидает EOS в 2025 году, так что да - придётся.

У меня ltsc, она до 2027.

т.е. грубо говоря вместо russian-blacklist можно этот файлик domains_all_withoutECH.txt со списком использовать?
И кстати почему в domains_all_withECH.txt есть домены 3-го уровня с www (например www.rutracker.org когда уже есть rutracker.org) или это просто особенность проверки была при формировании списка?

Ну так изначальный список же не мой. Я просто взял его с репозитория re-filter и прогнал по нему проверку наличия ECH. Почему там домены 3-го уровня - спрашивайте у них.

В теории да, можно использовать этот список вместо russia-blacklist. В крайнем случае, всегда можно легко вернуться к прежнему списку.

в запрете еще есть фильтр tcp port 80. Вот там по логике лучше исходный фильтра оставить? там то вообще нет SNI. Ну сайтов на чистом http конечно мало, тем более заблоченных, там только перенаправление обычно на https. Но по логике там тспу проверяют на поле Host заголовка?

это ясно. у меня вообще несколько батников не в режиме службы, так что проверяется легко.

Смотрю с чудо скриптами на batch покаончено и теперь go. Плюс скриптов был в том что в них можно было “подсмотреть” механизм проверки, тем более если это был вызов curl

Я сам продолжаю сидеть на batch версии, мне ее хватает более чем. На версию go переходить не собираюсь даже.

Несколькими постами выше лежит batch скрипт для проверки наличия ech у сайта. Там можете подсмотреть.

Ech, насколько мне известно, работает только с https, так что для 80 порта, конечно, этот список будет не особо полезен.

Впрочем, сайты без поддержки https - это вообще реликт прошлого. Я себе в браузере поставил режим принудительного https и хуже мне от этого не стало.

Вообще, можно поставить фильтрацию на 80 порт без хост листа. Не думаю, что это особо навредит, учитывая редкость чистого http.

А какому-нибудь рутор.инфо - стало. Просто пример, сам не понимаю, начерта это еще кому-то надо.

Увидел спасибо.
Грубо говоря запрос типа записи HTTPS и парсинг что в ответе есть поле ECH?

У них уже есть https.

Где он есть? Послать билеберду в ответ на запрос браузера - это не есть https ) Отбой, обходилка чертова ломает сервер хелло, через прокси все норм (

Обновление на основе вчерашнего листа от re-filter (22463 домена без ECH).
domains_all_2024_10_24_withECH.txt (344,7 КБ)
domains_all_2024_10_24_withoutECH.txt (402,2 КБ)

Можно просто DoH в браузере включить. Речь же шла об использовании DNS преобразователей системы.

Я, кстати, погуглил, и там есть какой-то лайфхак с реестром, чтобы включить системный doh в вин 10. Но у меня не заработало, увы.

Please permit me to correct you. TLS 1.3 has never been blocked in China. In reality, what was blocked in China in 2020 was not TLS 1.3, but only TLS connections using ESNI. See: Exposing and Circumventing China's Censorship of ESNI. Because ESNI required TLS 1.3, some news outlets published articles that unfortunately gave the impression that all TLS 1.3 was blocked in China, and the misconception persists to today.

There’s another important difference between ESNI in 2020 and ECH today. ESNI was never seriously deployed. Cloudflare had server support, but it was not enabled by default in any browsers. Nobody was actually using ESNI. That is why, when ESNI was blocked in China, it was only noticed by a specialist who was experimenting with some custom software. It was quite unlike the blocking of ECH in Russia in 2024, which was immediately noticed by thousands of ordinary users.

TLS 1.3 still works fine in China. As far as I know, there is no evidence of ECH being blocked in China. (Except for the DNS and DoH/DoT censorship that already happens there, which could have an effect on ECH.)

В Windows 10 использование системного резолвера включается настройкой network.dns.native_https_query_win10

Оно отключено по умолчанию, поскольку в Windows 10 вызов DnsQuery_A возвращает некорректное значение.

До тех пор, пока Microsoft не исправит ошибку, в Windows 10 следует использовать встроенную в Firefox реализацию DoH.

Yeah, I’ve already found it out. It’s just that I’d seen it mentioned everywhere on reddit, so I simply took it as a proven fact. What can I say? A classic case of a lie being repeated too often…
Kinda reminded me of a Kurzgesagt’ video I watched a week ago, about something widely accepted, but ultimately untruthful. Though it’s unrelated, uh.

Anyway, thank you for the further clarification!

там curl вышел 8.11, есть какая то фишка с ECH, вдруг тебе полезно будет для скриптов\прог
https://www.opennet.ru/opennews/art.shtml?num=62222

В dnscrypt-proxy есть встроенный DoH сервер, я запускал, браузер ругается что незащищённое соединение или сертификат. Ума не хватило решить с этими сертификатами, не пойму что ему нужно.