Комментарии 33
Что помешает подменять публичный ключ на известный тебе при запросе его из DNS? Насколько я помню, доля зон с DNSSEC довольно мала
Прямо в статье же:
Убедиться, что у вас есть включен DNS по HTTPS (DoH):
По аналогии с SNI, предположу, что ESNI — это расширение TLS и тогда он к DoH напрямую не относиться и это два параллельно развивающихся концепта. Хорошо что вопрос пользовательской криптографии развивается, но пока это лишь концепты. И обрести жизнь может любой из них и ни один из них.
Кстати, насколько DoH медленее чем обычный через UDP? Я бегло поискал, но не нашел
Кстати, насколько DoH медленее чем обычный через UDP? Я бегло поискал, но не нашел
Я использую DoH на OpenWRT — разницы незаметно. Гораздо сильнее проявляется разница между обычным DNS-резолвером и резолвером, валидирующим DNSSEC. Ещё лучше скрадываются задержки TCP если использовать несколько разных DoH-резолверов и dnsmasq, отправляющий запросы сразу во все и принимающий наиболее быстрый ответ.
… Ну и главные каналы утечки информации — сами сайты. Скрипты, кросс-доменные запросы и прочие радости.
Цензорам придётся блокировать IP-адреса, а это сомнительная практика
В России, к сожалению, это мало кого останавливает. Заблокировать пару-другую миллионов IP? Пфф, да не вопрос.
Мне интересно, когда поддержка ESNI появится в веб-серверах?
ЗЫ: Mozilla — мои герои.
Мне интересно, когда поддержка ESNI появится в веб-серверах?Разработчики nginx говорят, что поддержка появится тогда, когда она появится в OpenSSL и\или BoringSSL. Для BoringSSL, судя по всему, уже есть приватные патчи.
А сколько времени сервер будет определять, ключом от какого домена зашифровано имя домена?
каким ключом шифруется имя хоста?
если ключ всегда один и тот же, то это ничем не отличается от открытого имени
если ключ всегда один и тот же, то это ничем не отличается от открытого имени
Из факта использования одного ключа не следует неизменность шифротекста.
публичным ключом, пришедшим от dns-сервера. Если у тебя есть домен foo.com, делаешь, условно, text-запись с публичным ключом. Браузер при попытке входа на foo.com берёт ip и публичный ключ, которым шифрует домен. И шлёт запрос по ip. Сервер имеет приватный ключ (админ сам создаёт пару, публичную часть которой кладёт в dns), поэтому может расшифровать запрашиваемый домен.
Там правда должна быть пачка тонкостей, когда один домен живёт на целой пачке ip-адресов, но было бы логично иметь по публичному ключу на ip-адрес.
Там правда должна быть пачка тонкостей, когда один домен живёт на целой пачке ip-адресов, но было бы логично иметь по публичному ключу на ip-адрес.
публичный ключ меняется раз в год, или когда там истекает срок,
так вот если домен, который не меняется, и ключ который не меняется в течении срока жизни ключа будут давать одну и туже комбинацию в зашифрованном виде.
чем список доменных имен отличается от списка доменных имен в зашифрованном виде, если они не меняются во времени?
так вот если домен, который не меняется, и ключ который не меняется в течении срока жизни ключа будут давать одну и туже комбинацию в зашифрованном виде.
чем список доменных имен отличается от списка доменных имен в зашифрованном виде, если они не меняются во времени?
В оригинальной статье blog.cloudflare.com/encrypt-that-sni-firefox-edition есть скриншот wireshark 
Хорошо видно, что шифруется имя сервера с помощью AES, и наверняка с рандомным ключем.
Т.ч. каждый запрос на один сервер будет разным.
Хорошо видно, что шифруется имя сервера с помощью AES, и наверняка с рандомным ключем.
Т.ч. каждый запрос на один сервер будет разным.
Все это чудесно. Но как, в этом случае, резать доступ в корпоративной среде к внешним сайтам с поддержкой ESNI?
Видимо только непосредственно на ПК пользователя.
В корпоративной среде — можно тупо по ip.
Ситуация, когда очень нужный сервис настолько невелик, что на его ip висят ещё 10 сервисов, доступ к которым дать нельзя, видится крайне маловероятной.
Ситуация, когда очень нужный сервис настолько невелик, что на его ip висят ещё 10 сервисов, доступ к которым дать нельзя, видится крайне маловероятной.
В идеале никак, ибо это явный случай нарушения приватности, против которого и идёт борьба.
MITM в ssl
Это хорошая новость. Сейчас блокировки РКН, кроме 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. Интересный вариант.
— перехват 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. Интересный вариант.
Не сработало на 68.0.1 (64-bit) Ubuntu (не Nightly). Видимо, спустя почти год не пошло в стандартный дистрибутив.
Как я понял, в настройках Firefox присутствуют две разные процедуры: включение DoH и включение ESNI. Но могут ли эти технологии работать самостоятельно, отдельно друг от друга? Серверу недостаточно иметь поддержку TLS 1.3, нужно еще дополнительно устанавливать примочку в виде ESNI.
Кстати говоря, сами криптографическте DNS-сервера тоже можно заблокировать.
Кстати говоря, сами криптографическте DNS-сервера тоже можно заблокировать.
Очень извиняюсь, но хотелось бы уточнить один момент: только у меня в 63 лисе нет в about:config параметра network.security.esni.enabled?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандарт Encrypted SNI реализован в Firefox Nightly