https://community.cloudflare.com/t/encrypted-client-hello-ech-are-being-enabled-again/700863/3
медленно выкатывают, у себя пока не решаются
В Chrome 128 тоже работает, отключить нельзя
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.* имеют вероятность тупо работать сейчас. Я уже обнаружил несколько сайтов которые тоже работают, причем так быстро что чувствуется как магия после годов использования проксей где медленная скорость уже привычна.
Непонятны три вещи:
откуда браузер знает, что вместо SNI rutracker.org
нужно сначала отправить SNI cloudflare-ech.com
и только потом rutracker.org
?
Браузеры, которые этого не умеют, теперь не смогут ходить на сервера cloudflare или для них оставлена какая-то лазейка?
Что будет, если 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”
И что эта абракадабра значит?
В двух словах:
кто рассказывает? DNS Cloudflare? Google? А DNS российских провайдеров рассказывают? А если не расскажут?
непонятно, почему браузер использует 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_name
s. 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