На данный момент, использование 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 заблокирует ваше соединение.
Один адрес, 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?
eSNI это очень плохая идея. Во-первых, сессию очень легко на мидлбоксе свалить в fall back на TLS 1.2. Во-вторых, DoH легко режется по SNI сам по себе, потому что из-за доступности и обратной совместимости большинство провайдеров поддерживают fallback to SNI (мы проверяли в лаборатории). Ну и пробинг, собственно, ловит и позволяет пресечь. Доступность теряется. Требовалось либо обеспечить глобальный переход всех и сразу, и без fallback - что невозможно, либо не заморачиваться вообще.
Как я понимаю, ESNI прежде всего сделан для защиты приватности, чтобы провайдер пассивно не мог анализировать пользовательское поведение на основании DNS-запросов и SNI в TLS, а не для предотвращения цензурирования доступа.
В общем и целом - да. Кроме того, всегда остается опасность подписывания сертификата мидлбокса у рутов, и незаметного подсматривания (peek или stare) доменного имени; ну и реверсивные прокси видят TLS полностью, о чем не стоит забывать.
Я бы насчет рутов не говорил “невозможно”. Вспомним Симантек и BlueCoat. Которые по сей день находятся в эксплуатации (есть доказательства).
Реверсивные прокси для кэширования полностью расшифровывают HTTPS. Кэшировать без расшифровки HTTPS трафик невозможно. Это мало кто знает - это не афишируется - но это так. Об этом следует помнить.
Они не стоят у провайдера, а если и стоят, то только специализированные, вроде Google Global Cache, который сам управляет всем.
В любом случае, это уже не по теме.
Они именно у провайдера и стоят. Cloudflare стоит прямо на провайдерах во многих случаях. GGC… я не могу это обсуждать, к сожалению. CDN это отдельная, очень нехорошая, тема, которую, к сожалению, считают к делу не относящейся. Просто я бы посоветовал не отмахиваться от этого, окей? Это все, что я могу сказать.
У домена cloudflare-dns.com, на котором расположен обычный DNS-over-HTTPS-резолвер от Cloudflare, такие же IP-адреса, что и у mozilla.cloudflare-dns.com, а значит, что он также не будет работать корректно в РФ через многих провайдеров.
Мне пишут:
[…] друг использует приложение Simple DNSCrypt с dns от cloudflare (DoH), периодически он просто падает.
[…]Падает не программа, а само соединение к https://cloudflare-dns.com/dns-query и в такой момент только через впн работает.
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.
