Pull to refresh

Comments 33

Что помешает подменять публичный ключ на известный тебе при запросе его из DNS? Насколько я помню, доля зон с DNSSEC довольно мала
Прямо в статье же:
Убедиться, что у вас есть включен DNS по HTTPS (DoH):
По аналогии с SNI, предположу, что ESNI — это расширение TLS и тогда он к DoH напрямую не относиться и это два параллельно развивающихся концепта. Хорошо что вопрос пользовательской криптографии развивается, но пока это лишь концепты. И обрести жизнь может любой из них и ни один из них.

Кстати, насколько DoH медленее чем обычный через UDP? Я бегло поискал, но не нашел
Я использую DoH на OpenWRT — разницы незаметно. Гораздо сильнее проявляется разница между обычным DNS-резолвером и резолвером, валидирующим DNSSEC. Ещё лучше скрадываются задержки TCP если использовать несколько разных DoH-резолверов и dnsmasq, отправляющий запросы сразу во все и принимающий наиболее быстрый ответ.

… Ну и главные каналы утечки информации — сами сайты. Скрипты, кросс-доменные запросы и прочие радости.

Это противодействие блокированию и слежению со стороны провайдера. А остальное на совести админа сайта.

Да нет совести ни у кого. Как минимум, реклама есть у всех — вот ваш персональный трекер.

С этим можно бороться плагинами блокировщиками.

Цензорам придётся блокировать IP-адреса, а это сомнительная практика

В России, к сожалению, это мало кого останавливает. Заблокировать пару-другую миллионов IP? Пфф, да не вопрос.

Мне интересно, когда поддержка ESNI появится в веб-серверах?

ЗЫ: Mozilla — мои герои.
Мне интересно, когда поддержка ESNI появится в веб-серверах?
Разработчики nginx говорят, что поддержка появится тогда, когда она появится в OpenSSL и\или BoringSSL. Для BoringSSL, судя по всему, уже есть приватные патчи.
Как разработчик одного SNI-capable HTTP сервера ответственно заявляю, что поддержка со стороны криптографической библиотеки не обязательна — выбор сертификата и обработка SNI идентификатора производится самим сервером.
А сколько времени сервер будет определять, ключом от какого домена зашифровано имя домена?

Читайте внимательнее, имя домена не шифруется ключами от доменов.


Хотя вообще это самое очевидное решение, непонятно почему оно не было сразу реализовано как опция для защиты SNI там где это применимо.

каким ключом шифруется имя хоста?
если ключ всегда один и тот же, то это ничем не отличается от открытого имени

Из факта использования одного ключа не следует неизменность шифротекста.

публичным ключом, пришедшим от dns-сервера. Если у тебя есть домен foo.com, делаешь, условно, text-запись с публичным ключом. Браузер при попытке входа на foo.com берёт ip и публичный ключ, которым шифрует домен. И шлёт запрос по ip. Сервер имеет приватный ключ (админ сам создаёт пару, публичную часть которой кладёт в dns), поэтому может расшифровать запрашиваемый домен.
Там правда должна быть пачка тонкостей, когда один домен живёт на целой пачке ip-адресов, но было бы логично иметь по публичному ключу на ip-адрес.
публичный ключ меняется раз в год, или когда там истекает срок,
так вот если домен, который не меняется, и ключ который не меняется в течении срока жизни ключа будут давать одну и туже комбинацию в зашифрованном виде.

чем список доменных имен отличается от списка доменных имен в зашифрованном виде, если они не меняются во времени?

Публичный ключь шифрует временный ключь. Временный ключь шифрует SNI. Благодаря временному ключу запросы на один и тот же домен будут разными.

В оригинальной статье blog.cloudflare.com/encrypt-that-sni-firefox-edition есть скриншот wireshark image
Хорошо видно, что шифруется имя сервера с помощью AES, и наверняка с рандомным ключем.
Т.ч. каждый запрос на один сервер будет разным.
Все это чудесно. Но как, в этом случае, резать доступ в корпоративной среде к внешним сайтам с поддержкой ESNI?

Видимо только непосредственно на ПК пользователя.

В корпоративной среде — можно тупо по ip.
Ситуация, когда очень нужный сервис настолько невелик, что на его ip висят ещё 10 сервисов, доступ к которым дать нельзя, видится крайне маловероятной.

Напомню что в новости упоминается CDN Cloudflare.

В идеале никак, ибо это явный случай нарушения приватности, против которого и идёт борьба.

Это хорошая новость. Сейчас блокировки РКН, кроме IP адреса, делаются такими способами:

— перехват DNS-запросов — DoH решает проблему
— провайдерский DNS-сервер блокирует запр. сайты
— чтение SNI в SSL трафике и блокировка по нему — ESNI решает проблему

Таким образом, если DoH и ESNI будут включены по умолчанию, для обхода блокировки по домену достаточно будет поменять DNS с провайдерского на 8.8.8.8, 1.1.1.1 или еще что-нибудь за пределами российской юрисдикции. В устройствах на Андроид часто встроен 8.8.8.8 по умолчанию.

Останутся только блокировки по IP. Их можно обходить, меняя IP адреса быстрее, чем провайдеры их блокируют (это не так дорого стоит). При этом каждому запрещенному сайту не обязательно покупать свои адреса — можно сделать единый «центр» обхода блокировок, предоставляющий меняющиеся IP адреса. Причем узлы с временными IP для обхода блокировки не обязаны быть мощными — это делается на уровне iptables и тут хватит машинки с 256 Мб памяти или даже меньше.

То есть фактически механизм блокировок перестанет работать «из коробки», без установки сомнительных опасных сторонних плагинов или программ, платных сервисов.

Будет интересно посмотреть, как продолжится битва. Я вижу такие варианты:

— РКН каждые 5 минут резолвит домен запрещенного сайта, провайдеры в срочном порядке вносят его в бан-лист. Это можно решить тем, что заблокированный сайт будет периодически отдавать IP адреса сбербанка, пенсионного фонда, госсайтов, вконтакте, mail.ru, создавая тем самым негативное воздействие на власть
— создается пограничный фаерволл, полностью отсекающий заграничный трафик — это будет самый веселый вариант, в ответ на это придется создавать внутрироссийский Tor и сидеть в нем. После введения наказания за Tor (им ведь пользуются террористы и наркоманы) и несколько показательных дел, энтузиасты прекращают его поддерживать.
— создается пограничный фаерволл, делающий MITM всему SSL трафику с блокировкой других видов шифрованного трафика. Для получения доступа к заграничным сайтам необходимо установить госсертификат (издевательская версия: госсертификат выдается на Почте России после заполнения и обработки заявки с указанием цели получения). Обходится вторым слоем шифрования внутри SSL. Минус — не работает из коробки и потому не будет использоваться людьми.
— создается пограничный фаерволл в рамках БРИКС — ерунда, братья-китайцы за деньги дадут нам китайские IP для обхода блокировки.
— создается дорогой умный пограничный фаерволл, анализирующий паттерны в трафике и блокирующий только немассовые протоколы вроде SSH, VPN, DoH. Нанимается большое число операторов и анализаторов трафика. Ютубчик работает, обход блокировок — нет.
— блокируется DoH или DNS-сервера с поддержкой DoH. Интересный вариант.
При этом каждому запрещенному сайту не обязательно покупать свои адреса — можно сделать единый «центр» обхода блокировок, предоставляющий меняющиеся IP адреса.

Если вспомнить, что РКН не поперхнувшись блокировал IP сразу подсетками вплоть до /10, то не всё так радужно на самом деле.
Не сработало на 68.0.1 (64-bit) Ubuntu (не Nightly). Видимо, спустя почти год не пошло в стандартный дистрибутив.
UFO just landed and posted this here

Действительно работает. Но только если включить DNS через HTTPS. Ну и на сайтах которые его поддерживают. Я кроме cloudflare.com таких не знаю.

Как я понял, в настройках Firefox присутствуют две разные процедуры: включение DoH и включение ESNI. Но могут ли эти технологии работать самостоятельно, отдельно друг от друга? Серверу недостаточно иметь поддержку TLS 1.3, нужно еще дополнительно устанавливать примочку в виде ESNI.
Кстати говоря, сами криптографическте DNS-сервера тоже можно заблокировать.
Очень извиняюсь, но хотелось бы уточнить один момент: только у меня в 63 лисе нет в about:config параметра network.security.esni.enabled?
Sign up to leave a comment.