Опять (https://dns.controld.com/comss) подводит. С ним в браузере Рутрекер не открывался, перешел на другие DNS - Рутрекер летает.
ну хз токда ето получается что мы впереди планеты всей по блокировкам 
Спойлер
Китай не обогнали
А так мы применяем китайскую идею, но со своим колоритом
Боремся с ветренными мельницами
Немного оффт: у друга не открывалась почта protonmail (не прогружалась страница после ввода пароля), он удалил сертификаты минцифры, которые ставил чтобы сайт сбербанка открывался, почта протон стала открываться. Возможно какое-то совпадение.
Спойлер
Эти сертификаты возможность нас послушать.
Поэтому у меня стоит ЯД для госуслуг
Зачем, правда, их вообще ставить, если можно ткнуть “перейти на сайт”.
Нашёлся способ с политиками.
Нужно создать файл /etc/opt/chrome/policies/managed/ech-disabled.json (все папки в пути тоже создать) с содержимым:
{
"EncryptedClientHelloEnabled": false
}
Для браузера Brave путь будет:
/etc/opt/brave/policies/managed/ech-disabled.json
А на винде правится в реестре. Обязательно только для win11. В win10 достаточно отключить DoH. Хотя, я бы и в win10 отключил ECH, но не отключал DoH. Зачем провайдеру днсы в чистом виде показывать?
Тут кто-то писал, что DoH это палево. Ну, ребята, я вообще трафик на один IP гоняю и ничего.
Если быть точнее, ECH (более новая технология). В ECH SNI есть всегда, но фейковый. Вот его и заблокировали (самую популярную реализацию от Cloudflare).
Там даже описана PowerShell команда, главное, от админа запускать, а то не пропишет ключи.
Спойлер
$PATH = "HKLM:\Software\Policies\Google\Chrome"
$NAME = “EncryptedClientHelloEnabled”
if (-not(Test-Path $PATH)) {New-Item -Path $PATH -Force}
New-ItemProperty -Path $PATH -Name $NAME -Value 0x0 -Force
С другой стороны, нужно ли отключать ECH. Не влияет ли это на безопасность подключения? Я в том плане, что сейчас мы дурим адрес CF и соединение, вроде, продолжает быть зашифрованным ECH или я дурак и вообще не так все понимаю?
Проверить успешность процедуры можно следующим образом. Вбиваете в адрес chrome://policy/, осуществляете поиск EncryptedClientHelloEnabled, значение должно быть на false.
Если хотите все вернуть обратно, то в редакторе реестра данный ключ будет находиться по адресу - HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
1 Like
Если есть дурение, конечно, ECH будет более приватным (провайдер не будет знать какие сайты вы посещаете, будет видеть только IP Cloudflare). Тогда лучше DoH и ECH не отключать.
freetp ru тоже пал, с org заходит (
почти угадал) судя по всему связано с этим: (у меня правда все работает)
вот оно чё, значит хабор там хостица
Не могут, потому что для внешнего SNI нужен валидный сертификат, а бесконечного числа лишних доменов у клаудфляры всё-таки нет.
Что-то с ungoogled chromium это не работает. В chrome://policy/ пусто.
Новый Brave вроде принимает.
При этом, кто тестит под варпом, имейте в виду, что там ech почему-то вообще не работает.
А разве habr.com не хостится на hll llc?
habrastorage.org на хетцнере
Is there also an announcement from Roskomnadzor? I know only of the notice from ЦМУ ССОП linked at Обсуждение: Блокировка (замедление) ECH Cloudflare - #227 by Istr.
EDIT: Ok, I see at Роскомнадзор рекомендует отключить шифрование ECH от Cloudflare или перейти на отечественные CDN that ЦМУ ССОП is “Roskomnadzor’s monitoring center.”
https://ntc.party/t/12837 says “Блокировка осуществляется, если в пакете ClientHello установлен SNI = cloudflare-ech.com и есть ECH extension” – “Blocking is done if, in the ClientHello packet, the SNI is set to cloudflare-ech.com and there is an ECH extension”.
I assume that an ECH extension means, at least, ExtensionType 0xfe0d from draft-ietf-tls-esni-22. Do you know if any other ExtensionTypes are affected?
| encrypted_client_hello ExtensionType | version | date |
|---|---|---|
| 0xfe0d | draft-ietf-tls-esni-13 | 2021-08-12 |
| 0xfe0c | draft-ietf-tls-esni-12 | 2021-07-07 |
| 0xfe0b | draft-ietf-tls-esni-11 | 2021-06-14 |
| 0xfe0a | draft-ietf-tls-esni-10 | 2021-03-08 |
| 0xfe09 | draft-ietf-tls-esni-09 | 2020-12-16 |
| 0xfe08 | draft-ietf-tls-esni-08 | 2020-10-16 |
| 0xfe02 | draft-ietf-tls-esni-07 | 2020-06-01 |
The older ExtensionTypes may not interoperate with the current Cloudflare ECH deployment – but by checking for packet dropping it still should be possible to see whether they are being specifically blocked.
With the blocking of ESNI in China back in 2020, only the specific ExtensionType 0xffce was blocked, not others like 0xff02, 0xff03, and 0xff04. (However, I consider the tests that were done back then inconclusive, because Client Hellos containing the other ExtensionTypes were not well-formed.)
Can you say more about this? What I understand is that browsers will eventually retry the connection without ECH (with plaintext SNI).
- In Chrome, after clicking “Reload” several times.
- In Firefox, after waiting a few minutes.
(Also reported here: “в Firefox 131 сайты с ECH открываются без ECH через минуту «загрузки» — открывается новое соединение с plain SNI, а старое закрывается.”)
Do I understand correctly about browsers falling back to non-ECH?
У меня адгуард с DOH поднят уже давно, но хост не особо публичный и только с определенным идентификатором разрешено подключение. Вроде пока все норм.