Firefox + Encrypted Client Hello + DNS over HTTPS

,

Заметил что некоторые заблокированные сайты начали открываться после включение в Firefox “Encrypted Client Hello” и “DNS over HTTPS” без каких-либо инструментов обхода. Видимо включение ECH помогает заходить на заблокированные по имени домена сайты. Интересно как долго по времени будет работать данная технология до блокировки роскомпозором

В этих браузерах во flags включил ECH, а также DoH (Cloudflare) в настройках.
Opera (Chromium 109), Win7, Ростелеком
Brave (Chromium 107, окт 2022), Xubuntu 22.04, Yota
Заблокированные сайты (например, Rutracker, он за Cloudflare) не открываются.
Браузеры слишком старые?

В Firefox и Cloudflare включена поддержка ECH для скрытия домена в HTTPS-трафике :

В Chrome поддержку ECH начали постепенно включать, начиная с выпуска Chrome 115.

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

Вот эти сайты говорят, что ECH включен
https://crypto.cloudflare.com/cdn-cgi/trace (sni=encrypted)
https://defo.ie/ech-check.php
А здесь https://defo.ie говорится, что поддерживается в Chromium 105+ (если включить во флагах + DoH).
Однако, при попытке открыть рутрекер:
Этот сайт не может обеспечить безопасное соединение
Сайт rutracker.org отправил недействительный ответ.
ERR_SSL_PROTOCOL_ERROR
В Brave (Chromium 107).

UPD: Работает в Firefox 118 с такими настройками:
network.dns.echconfig.enabled - True
network.dns.http3_echconfig.enable - True
network.dns.force_waiting_https_rr - True
security.tls.ech.grease_probability - 100
security.tls.ech.grease_http3 - True

Рутрекер открывается (на Yota). Но важное условие - не нужно отключать HTTP3 (QUIC). Т.е. сайты должны быть не только под Cloudflare, но и поддерживать HTTP3 (он работает по UDP протоколу). Отключаешь HTTP3 и перестает открываться рутрекер. Раньше некоторые его отключали чтобы не тупили сайты из-за блока QUIC у провайдеров и потому что есть риск утечки мимо прокси (кто использует прокси).

Пишут, что ECH появился в Chrome 105. Но включили по умолчанию позднее и, возможно, в старых версиях хрома поддерживается более ранний стандарт. Я включил QUIC и ECH в Chromium 107 и 109, но рутрекер не открывается. 109 последняя версия для Win7.
Хорошо бы составить список какие сайты это разблокирует. Пока что пользы мало.

Просьба писать источник данных
https://wiki.mozilla.org/Security/Encrypted_Client_Hello
Вот тут более подробно технически и с небольшими пояснениями как и что в Firefox

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

У рутрекера нет ключа в днс записи
У crypto.cloudflare.com и defo.ie есть. Без ключа не будет ECH.

QUIC работает по другой причине, без ключа там тоже нет ECH.

Парсер сложного QUIC у ТСПУ простой, был и возможно еще есть. Изначально все ошибки парсера, и как результат неизвестный SNI, приводили к блокировке. Парсер улучшали, он стал понимать фреймы Chrome. Отменили блокировки для недоступного SNI. Но Firefox все еще делал “неправильные” пакеты, и парсер не мог достать SNI. Цензор разрешал такой трафик, потому что узнать о наличии и использовать h3 можно только подключившись через TLS с читаемым SNI, или сделав дополнительный (лишний) DNS запрос. С включением ECH запрос делать нужно, поэтому информацию о протоколах Firefox может получить до подключения к сайту.

На сколько я понял из описания, это будет работать только для сайтов, расположенных в cdn.
В открытом виде все-равно передается общий домен, и РКН заблокирует его на раз-два, как и QUIC.
Ну и от блокировки по IP это тоже не спасет.

Теоритически и технически - нет. Вот тут:

написано “а также общее имя домена, которое не пересекается с фактическим именем запрошенного домена”. Но цензор может наложить бан на все пакеты идущие на определённый IP. Даже если на этом IP крутится несколько сайтов.
Почему надежда на “CDN” с поддержкой ECH? Потому что там за 1им IP скрывается слишком много сайтов и есть риск забанить себе полинтернета.

Вот только у РКН уже есть опыт блокировки половины интернета. Что их остановит от повторения?

CF с февраля’22 увеличил число ДЦ в РФ, думаете будут рисковать из-за ECH?

да как я понимаю они уже пихают общий хост cloudflare-ech.com. По нему весь этот трафик и порежут. То есть cloudflare как бы сдал всех сразу.

Можно использовать другой домен, который проксируется CF. Пока запретов на домены для ECH у CF не обнаружено. Впрочем, пользовательский софт так делать не будет.

Потестировать можно собрав неофициальные openssl и curl с поддержкой ECH.

У меня curl заработал только в статичной сборке (--disable-shared).
Сборка (для упрощения, без поддержки днс запросов) такая:

LDFLAGS="-L$HOME/code/openssl" ./configure --with-ssl=$HOME/code/openssl --enable-ech --disable-shared

Через ECH конфиг с днс иногда (всегда) не получается сразу получить http ответ, но сервер в таком случае может вернуть нужный через retry_configs в TLS. Если curl не повторил запрос с новым конфигом, нужно будет копипастить.

src/curl -vvv --ech ecl:<base64_config> --ech pn:<SNI> https://site

Если не лезть в Wireshark, можно начать тесты с defo.io, где показывают используемый SSL_ECH_OUTER_SNI

usnevst
Подскажите как сделать поддержку Secure SNI в openwrt, что для этого надо, какие пакеты и как настроить если вы в курсе ?
Включил в мозиле и да, реально стали открываться сайты, хотелось бы это сделать на уровне роутера

Cloudflare отключил ECH у себя везде до следующего года

Нет, не знаю. ClientHelloOuter (где передают публичный SNI) и ClientHelloInner (где спрятан оригинальный SNI) связаны, как минимум у них есть новое TLS расширение. Невозможно взять ClientHello от браузера (приложения) и завернуть в ClientHelloOuter, превратив в ClientHelloInner без модификации самого ClientHello, если приложение не использует ECH. Это сломает TLS протокол.

User69
Не знаю что они там отключили, но пока что всё работает на данный момент