Преимущества ESNI
- Никто не видит на какой домен вы заходите. Все что знает провайдер это только IP адрес на который вы обращаетесь.
- Domain Fronting не нужен.
Как ESNI работает
В современном интернете на одном IP адресе может располагаться множество различных доменов. Чтобы предоставить вам верный сертификат серверу необходимо знать на какой именно домен вы обращаетесь. Поэтому hostname передается открытым текстом, до начала установления TLS сессии.
Схема работы SNI
ESNI шифрует и эту часть общения клиента с сервером. Клиент берет публичный ключ сервера из DNS и шифрует им все данные до установления TLS сессии.
Схема работы ESNI
Ложка дегтя
ENSI сильно зависим от DNS. Настолько сильно что при текущей реализации DNS (plain text) поставить DPI на DNS протокол и блокировать все поля с публичными ключами серверов элементарно. Эта проблема исправима только массовым переходом на DNSSEC или DNS over HTTPS. Судя по блогу разработчиков Хрома этот переход уже не за горами.
ESNI должен поддерживаться браузерами. Пока с поддержкой не очень.
Что мы от этого получим?
Цензура в интернете сильно усложнится. Сейчас большинство блокировок происходит по DNS именам. Все эти блокировки перестанут работать. Останутся только блокировки DNS запросов или IP адресов.
Блокировки DNS запросов перестанут работать после включения по умолчанию DNS over HTTPS в стандартных браузерах. И останется только одна возможность блокировать по IP адресам. Можно блокировать или DNS сервера или неугодные сайты.
Блокировки по IP адресам это для очень смелых людей. Одной блокировкой может зацепить множество непричастных доменов и нет адекватного способа проверить заранее кого именно зацепит. А блокируемый сервис может в пару кликов, да и вообще автоматически, сменить адрес на не заблокированный. Его пользователи даже ничего не заметят.
Итого
Жизнь станет чуть-чуть лучше. Но не сейчас. До полноценной поддержки ESNI еще необходимо сделать несколько шагов.
Ссылки
Проверить свой браузер на поддержку TLS 1.3, ESNI и шифрование DNS можно тут.
Комментарии (29)
dartraiden
29.09.2018 20:43+5IPFS-шлюз, упрощение жизни пользователям Tor, ESNI — CloudFlare становится новой «корпорацией добра».
dollar
29.09.2018 20:43+3Мне уже страшно.
Сейчас провайдер видит домен в запросе и может блокировать по домену. Если на том же ip находятся другие сайты, то они остаются доступны.
А теперь провайдер будет видеть только соединение по ip, на котором размещён запрещённый Роскомнадзором сайт, и будет вынужден блокировать по ip.
Я, конечно, понимаю, что качеством блокировок никто толком не озаботился в нашей стране. Но давайте представим, что оно высокое — и 99% vpn, а также всякие tor заблокированы. Тогда полное шифрование тоже не останется без внимания.dartraiden
29.09.2018 20:47Два положительных момента:
— больше людей настроят обход блокировок, повысив техническую грамотность (чтобы попасть на свои любимые сайты, сидящие на тех же IP)
— больше людей будут возмущены, а это напрямую влияет на решение «блокировать или нет». Именно из-за таких вероятных последствий YouTube и Википедию отдают провайдерам на блокировку исключительно с протоколом http (они всё равно не доступны по http, поэтому блокировка доступа к ним по http никого не затрагивает, но позволяет формально их заблокировать).
Sabubu
29.09.2018 23:35+4> Блокировки по IP адресам это для очень смелых людей. Одной блокировкой может зацепить множество непричастных доменов и нет адекватного способа проверить заранее кого именно зацепит.
Как будто в нашей стране это кого-то беспокоит. Если надо, будут блокировать сразу подсетями, как показывает опыт.Arqwer
30.09.2018 00:22+2Опыт показывает, что за блокировку подсетями всё-таки ругают, и РКН от этого отказался.
SagePtr
30.09.2018 03:07+1Не отказался, просто новые диапазоны IP-адресов пока что не вносит, но и старые убрал далеко не все. Часть диапазонов Amazon и DigitalOcean в реестре всё ещё есть, и очень часто попадаю на ресурсы, находящиеся в запрещённых диапазонах IP.
Bsplesk
30.09.2018 12:50Telegram — работает, а мой сайт(Digital Ocean) так и не разблокировали.
Но даже не думаю переходить на РФ хостинг.
Если раньше рассматривал хостинг в РФ в качестве кандидатов — то теперь они все занесены в Black list.
firk
30.09.2018 02:23-1Какая наивность. Как в отношении блокировок, так и в целом.
Для начала надо разделить две ситуации: 1) один сервер, по сути один сайт но разбросан по разным доменам из сео- или других соображений: TLS терминируется и обслуживается владельцем сайта: 2) много независимых друг от друга хостов на одном ip-адресе: TLS (по крайней мере SNI) терминируется третьим лицом — владельцем ip-адреса. Очевидно что во варианте [1] речь идёт по сути о шифровании внутрисайтового урла, залезшего в область доменных имён, и этот случай мало кого может волновать, и в статье написано не про это.
Никто не видит на какой домен вы заходите. Все что знает провайдер это только IP адрес на который вы обращаетесь.
Как "ловко" приравняли "никто не видит" и "провайдер не узнает". Если второе в теории ещё возможно, то первое — очевидное враньё. Третьи лица обязательно увидят весь маршрут вплоть до точки входа во владения владельца сайта. Этими третьими лицами не обязательно будет провайдер, в данном случае это будет тот кто управляет мультиплексором хостов на ip-адресе.
(касательно блокировок)
С нормальным SNI у вас была возможность показать провайдеру, что вы хотите посетить незаблокированный сайт при том что айпи его имеется в списках на проверку из-за ещё кого-то, а с шифрованным SNI вы от этой возможности отказываетесь — ну, ваше право, но какая от этого польза — непонятно совсем.
ProstoUser
01.10.2018 15:24Третьи лица обязательно увидят весь маршрут вплоть до точки входа во владения владельца сайта. Этими третьими лицами не обязательно будет провайдер, в данном случае это будет тот кто управляет мультиплексором хостов на ip-адресе.
Задачи спрятать целевой домен от того, кто управляет мультиплексором хостов на IP адресе, не стоит. :-) Это, я думаю, хостинг-провайдер, который и так все знает про ваш сайт. Ему нет никакого смысла фильтровать пользователей вашего сайта. это не в его интересах.
Защитить свой сайт надо от того провайдера пользовательского доступа, который находится в РФ под контролем РКН и в силу этого вынужден осуществлять цензуру исходящих соединений.
С нормальным SNI у вас была возможность показать провайдеру, что вы хотите посетить незаблокированный сайт при том что айпи его имеется в списках на проверку из-за ещё кого-то, а с шифрованным SNI вы от этой возможности отказываетесь
Насколько я понимаю, сейчас провайдеры выгружают из РКН список блокировок и там указаны либо URL-и, либо IP адреса. Соответственно они блокируют что-то по именам, а что-то по адресам. Про то, что бывают записи вида «блокировать такой-то IP адрес, кроме тех, кто идет туда за сайтами отличными от [DNS-Name].com», я не слышал.
belyvoron
30.09.2018 09:15вагную сценарий:
в паблик интернете ESNI на IP из запрещенного пула будет дропаться. И появится рекомендация, что если вам нужно на легитимный ресурс, случайно попавший под блокировку, выключить ESNI в настройках браузера
в корпоративной среде ESNI будет выключен политиками, разлитыми через AD. Весь ESNI трафик, если такой окажется, будет дропаться. Хотя если в компании внедрена полноценная HTTPS инспекция, то в этом нет необходимости.BugM Автор
30.09.2018 13:00-1Люблю я такие прохладные истории. А теперь вспоминаем что сейчас век мобильных устройств. Все сидят в телефонах. Про политики сразу забываем. Про отключение в настройках так же забываем. 95% пользователей используют все по умолчанию. И если не работает сильно ругаются. Представить себе полезный и нужный по работе сайт использующий ESNI очень просто. Админ заблокировавший такое быстро оправится на ковер к начальству, а потом на мороз.
А еще больше я люблю вообще морозные истории про «полноценная HTTPS инспекция» ее никто никогда не видел, но все пугают.
Про блок по IP я написал. Никто ничего у себя включать/выключать не будет. Те кто на такое способны поставят vpn, остальные будут ругаться. Владельцы заблокированных до кучи сайтов буду судиться.belyvoron
30.09.2018 13:44+1мобильных устройств и по работе — вещи немного несовместимые. Политики замечательно накатываются на рабочие ПК. А мобильные устройства пока плохо совместимы с корпоративно средой.
HTTPS инспекцию я не то, что видел, я её внедрял и не раз. Понимаете, в компаниях, которые заботятся о своей безопасности, принято проверять интернет-трафик. А так как в сети половина трафика — HTTPS, то его надо расшифровывать. Иначе, здравствуй Петя и убытки в миллионы зеленых.
Стремление к приватности понятно, но оно сталкивается с бизнесом и правительствами, которым нужна открытость.
По поводу того, что никто не будет включать-выключать — спорить бесполезно, жизнь покажет.raskal
01.10.2018 13:20Поделитесь списком компаний, если имеется — ну, чтобы туда не ходить на собеседования.
По факту — никто не расшифровывает HTTPS с подменой посередине сейчас, обычно просто black/whitelist держат. В век BYOD было бы странно наблюдать иное.
BugM Автор
01.10.2018 13:51Вы неверно мысль сформулировали.
Правильно будет так: Корпоративная среда (в вашем понимании этих слов) несовместима с современным миром. Без мобильных устройств сейчас и жизнь и работа просто невозможны.
И естественно никто ничего не расшифровывает и сертификаты не подменяет. Есть какое-то количество неадекватных фирм, я подозреваю что госы сплошь, которые могут такой фигней заниматься. С ними лучше не связываться. Если пришлось по проекту с ними общаться, то это обычно бывает так: Есть супер защищенная с митм сеть. А есть рядом стоящие ноутбуки на которых все и работают. Они смотрят в Интернет через обычный 4Г. И если что-то нужно в супер защищенной сети просто через флешку копируют.
И с почтой все забавно.
— Куда вам написать? Вот на этот адрес с визитки?
— Это рабочий вы лучше на него не пишите, он работает плохо. И не пропускает ничего. Пишите сюда на мой личный. И дают обычный gmail.
А чего спорить? История уже доказала что оно просто начнет работать у всех с какого-то момента. Как HTTPS. Очень долго говорили: Ну зачем? Большинству сайтов нечего шифровать. Это медленно, долго и сложно. Прошло время и теперь сайтов без HTTPS просто не осталось.ProstoUser
01.10.2018 15:32Вы не вполне понимаете корпоративную среду. :-)
Есть супер защищенная сеть без митм. Как, впрочем, и без доступа к Интернету вообще.
Есть стоящие рядом ноутбуки, с которых можно ходить в Интернет, но на которых уже стоит корневой сертификат, обеспечивающий митм при работе через корпоративную сеть. Флешки отключены на всех компах без исключения и пользователи никогда не имеют админского доступа.BugM Автор
01.10.2018 15:40Я не просто понимаю я с ней работал.
Тогда ставится рядом второй ноутбук с обычным 4Г.
Не работает вся эта схема с митм. Поставить можно. Внедрить можно. А работать не будет. В лаборатории без проблем, на реальных сетях не работает.
Сеть без интернета без проблем работает. Сценарий точно такой же. Рядом стоит ноутбук с 4Г. Только добавляется куча гемороя с обновлением всего и вся. Или пишутся смешные документы что мол у нас интернета нет и вообще все защищено и обновлений нам не надо. Живут такие документы до первого шифровальщика.
Ну не флешки, так какая-нибудь хитрая почта или шара в сети через которую все что угодно переслать можно. Проблема с невозможностью пересылки решается примерно через неделю-две после внедрения вот этого вот всего. Рабочий процесс встает и все быстро решается. Неофициально естественно.ProstoUser
01.10.2018 16:23Второй и даже третий ноут с 4Г поставить рядом можно. Проблема в том, что нет возможности с него что-либо переписать или другим путем передать на тот ноут, что в корпоративной сети. Не забывайте, админских прав ни у кого нет.
Все обновления (одобренные местными админами) работают с корпоративных серверов обновления, куда админы их выкладывают. Есть шара с «разрешенным» софтом, где можно найти практически что угодно.
Конечно, обходные пути всегда есть, но опять же, периодически запускается скрипт, который удаленно смотрит, что и на каком компе установлено и если что-то левое, то приходится объяснять, каким образом это туда попало.
Вообще, на мой взгляд, разумный подход. Бизнес-пользователи не обладают знаниями для того, чтобы подобные ограничения обойти. А IT-шники если что-то и обходят, то делают это достаточно разумно, чтобы не поломать безопасность.BugM Автор
01.10.2018 16:45А зачем админские права чтобы файликами кидаться? Есть аккуратненькая дырочка сквозь вот это вот все чтобы можно было передавать файлы. Без этого встает рабочий процесс. По регламенту работать невозможно.
Вот это я люблю. Одобренные местными админами! Как серьезно звучит. Как будто хоть один админ или даже целый отдел способен разобраться хотя бы в MS или Оракловых апдейтах. Не говоря уже обо всем остальном софте. Никто ни в чем естественно не разбирается. И даже не пытается разобраться. Хорошо если ставят достаточно быстро. Или не ставят и ловят шифровальщиков. В итоге дополнительный геморрой для админов на пустом месте.
Всем кому надо по работе, а это большая часть сотрудников уровнем выше дворника, приходят местные айтишники и все настраивают сами. И софт ставят и дырочку для передачи файлов делают. По негласному распоряжению руководства. Работать как-то надо.
ReklatsMasters
30.09.2018 10:43Меня немного напрягает то, что ESNI всё ещё в статусе черновика, а значит что на пути к RFC спека ещё может измениться.
blind_oracle
01.10.2018 00:02Бесполезная штука.
DNS-запрос перед TLS-хендшейком раскрывает все карты — умные DPI без проблем сложат два и два.
Единственный способ это скрыть — DNS-over-TLS/HTTPS — то еще уродство, к сожалению. Чтобы сделать DNS-запрос нужно пройти TLS-хендшейк, проверить цепочку сертификатов и тп — это сильно повышает латентность и нагрузку. А если туда еще и HTTP внутрь запихали… Кэширование сессий помогает, но полностью проблему не решает.
С другой стороны хорошее решение этой проблемы в голову тоже не приходит. DNSCrypt вроде бы ничего, но он еще дальше от реальности чем вышеуказанные протоколы…
Meklon
Жду, пока Nginx mainline пакеты обновит и можно запускать) в репозиториях пока собран со старым OpenSSL.
BugM Автор
Да рано еще. Можно не суетиться до НГ точно.
Meklon
Даже так? Тогда, наверное, стоит самому всё-таки собрать.
glowingsword
Так ESNI должен поддерживаться не только свежей OpenSSL, но, как я понимаю, и самим Nginx. Так как себе для VPS-ки собрал Nginx с последним OpenSSL, TLS 1.3 работает, но с ESNI беда — его нет.