Комментарии 39
С точки зрения взаимодействия пользователя с блокировками ECH/eSNI скорее плохо, чем хорошо: как только DPI станет бесполезным для блокировок, станет бесполезным и абьюз DPI для их обхода.
остается наблюдать, что будет дальше.
Очевидно же, что раз
ECH делает невозможными точечные блокировки сайтов
То во имя противодействия угрозам суверенному интернету вернутся к практике бана подсетями. Оставлять угрозы незаблокированными с формулировкой "не шмогли" никто не станет.
ECH не отличим от обычного HTTPS с SNI и содержит в себе outer SNI который будет считываться ТСПУ. Пока этот outer SNI не меняется для CDN Cloudflare и содержит в себе домен cloudflare-ech.com. Поэтому вначале будет бан на ТСПУ по домену cloudflare-ech.com.
Если дальше продумывать действия регулятора, то будет логично сделать ротацию доменов в outer SNI, но для каждого домена нужно будет выпускать свой сертификат. (Хотя для того же VLESS это не является проблемой).
Уже банят(не рф). Правда хохма в том, что файрфокс не может соединиться, а хром может(кажется что парсер QUIC не завезли в мой dpi)
Пока этот outer SNI не меняется для CDN Cloudflare и содержит в себе домен cloudflare-ech.com
Интересно, откуда клиент знает, что надо передавать cloudflare-ech.com в outer SNI, при подключении к сайту за cloudflare? Он же вообще не знает, что это cloudflare.
Клиент через DNS получает начальные параметры, необходимые для работы ECH
Т.е. в NS-записи mysite.com будет написано: в outer sni передавай cloudflare-ech.com? А зачем?
Потому что совсем без SNI не получается.
Там идея (если забыть про Cloudflare): клиент передаёт в outer домен example.com, а в inner - secret.example.com
В результате, внешний наблюдатель лишается возможности понять, куда идёт клиент, т.к. видит лишь outer.
ECH разрабатывался, в первую очередь, не против блокировок, а против слежки. Но, т.к. Cloudflare очень крупная, то появляется приятный побочный эффект - она может собой прикрывать своих клиентов, и цензору придётся стрелять себе в член и блокировать cloudflare-ech.com
Меня ещё это ввело в недоумение
будет логично сделать ротацию доменов в outer SNI, но для каждого домена нужно будет выпускать свой сертификат
как будто, сертификат нужен на outer domain, а не на inner.
Тогда злоумышленник, захвативший DNS, сможет организовать подмену сайта, подставит в outer domain домен, на который у него есть сертификат.
Проверять же оба сертификата - и outer, и inner - не будет ли избыточным.
Странная система.
Если уж работаем с dns, почему бы не раздавать через dns публичный ключ и не шифровать им sni? Зачем вообще нужен этот outer sni?
Ну просто публичный ключ достаточно длинный и без соли не поможет, т.к. список доменов конечный и очень небольшой. Очень быстро можно составить базу соответствий. Потом надо защититься от MITM. И так далее.
В итоге будет еще один дублирующий механизм. А зачем если уже есть SSL? Соединяемся с неким общим доменом и с него берём (или отдаём) всё, что нам надо.
Ну и тот же CF вполне может лоббировать свою незаменимость.
Так то какой-то шифрованный SNI вроде уже был.
просто публичный ключ достаточно длинный
ed25519 - 68 ascii (base64) символов, что существенно меньше любых встречающихся ограничений на длину dns-записи
без соли не поможет, т.к. список доменов конечный
Никто не шифрует открытым ключом домен непосредственно данные: шифруют случайный ключ симметричного алгоритма, которыми затем шифруют данные (в данном случае - домен). Chosen plaintext атаку провести не получится.
из всей статеи наиболее интересным оказалось: "на сайте известного русскоязычного СМИ из 6 букв в зоне .io". до сих пор разгадываю - сижу.)
неужто metamorphosa.io ?
Если СМИ занимается той же пропагандой, но с другой стороны забора, то это не делает его приличным
я не уверен, что можно тут полное имя писать
а я уверен что можно.
https://ru.wikipedia.org/wiki/Мезуза
Ладно, придёт поручик и всё опошлит - это медуза.
а с октября 2024 года он доступен снова, в том числе для сайтов, использующих бесплатный тариф.
Интересный способ сказать "принудительно включён".
а он может как то навредить?
Я не говорю, что это плохо, я даже за, просто будьте готовы к последствиям.
We chose cloudflare-ech.com as the SNI that all websites will share on Cloudflare
https://developers.cloudflare.com/ssl/edge-certificates/ech/
Когда РКН, КПК и другие товарищи забанят канарейку cloudflare-ech.com, сайты с бесплатного таера перестанут открываться. И владельцы не смогут это отключить.
В лучшем случае будут травить DNS. Собственно, подмена DNS - это и есть контент-фильтр здорового человека (например семейный DNS на домашнем роутере 1.1.1.3, 77.88.8.7).
На самом деле, плохая новость. Если не получится забанить соединения, использующие ECH - то в итоге забанят весь cloudflare. А это очень большой кусок интернета.
Когда DPI мог банить отдельные ресурсы - они этим ограничивались. Можно было спокойно заводить VPN с маскировкой под https. Теперь блокировки ужесточатся.
Логично было бы забанить ECH в зародыше, пока он ещё не набрал популярность. Но выше написали, что ECH находится под TLS, и поэтому нельзя отличить ECH-соединение от обычного SNI.
А я-то думаю, чего это мой Белтелеком в Беларуси начал подменять DNS-ответы при запросах к публичным серверам уже несколько дней как. А вот оно чё, оказывается. Видимо, приходится вертеться в свете недоступности SNI для ресурсов, которые надо блокировать...
Интересно, что они с DNSSEC делают
ДОМ.РУ в РФ уже лет 10 подменяет, для снижения нагрузки на DPI.
Интересно, что они с DNSSEC делают
С этим всё понятно - забанят и скажут "у вас есть провайдерский DNS".
Что делать с DoH - вопрос интересный. Скорее всего, забанят по IP крупные DoH-сервисы (Mozilla, Quad9, Google и т.п.), а вылавливать всю мелочь не будут.
Cloudflare активировала ECH на своих серверах