Pull to refresh

Comments 33

Жду, пока Nginx mainline пакеты обновит и можно запускать) в репозиториях пока собран со старым OpenSSL.
Да рано еще. Можно не суетиться до НГ точно.
Даже так? Тогда, наверное, стоит самому всё-таки собрать.
UFO just landed and posted this here
Мне уже страшно.
Сейчас провайдер видит домен в запросе и может блокировать по домену. Если на том же ip находятся другие сайты, то они остаются доступны.
А теперь провайдер будет видеть только соединение по ip, на котором размещён запрещённый Роскомнадзором сайт, и будет вынужден блокировать по ip.

Я, конечно, понимаю, что качеством блокировок никто толком не озаботился в нашей стране. Но давайте представим, что оно высокое — и 99% vpn, а также всякие tor заблокированы. Тогда полное шифрование тоже не останется без внимания.
Два положительных момента:
— больше людей настроят обход блокировок, повысив техническую грамотность (чтобы попасть на свои любимые сайты, сидящие на тех же IP)
— больше людей будут возмущены, а это напрямую влияет на решение «блокировать или нет». Именно из-за таких вероятных последствий YouTube и Википедию отдают провайдерам на блокировку исключительно с протоколом http (они всё равно не доступны по http, поэтому блокировка доступа к ним по http никого не затрагивает, но позволяет формально их заблокировать).
> Блокировки по IP адресам это для очень смелых людей. Одной блокировкой может зацепить множество непричастных доменов и нет адекватного способа проверить заранее кого именно зацепит.

Как будто в нашей стране это кого-то беспокоит. Если надо, будут блокировать сразу подсетями, как показывает опыт.

Опыт показывает, что за блокировку подсетями всё-таки ругают, и РКН от этого отказался.

Не отказался, просто новые диапазоны IP-адресов пока что не вносит, но и старые убрал далеко не все. Часть диапазонов Amazon и DigitalOcean в реестре всё ещё есть, и очень часто попадаю на ресурсы, находящиеся в запрещённых диапазонах IP.
UFO just landed and posted this here
аналогично с DO, перешел на hetzner

Какая наивность. Как в отношении блокировок, так и в целом.


Для начала надо разделить две ситуации: 1) один сервер, по сути один сайт но разбросан по разным доменам из сео- или других соображений: TLS терминируется и обслуживается владельцем сайта: 2) много независимых друг от друга хостов на одном ip-адресе: TLS (по крайней мере SNI) терминируется третьим лицом — владельцем ip-адреса. Очевидно что во варианте [1] речь идёт по сути о шифровании внутрисайтового урла, залезшего в область доменных имён, и этот случай мало кого может волновать, и в статье написано не про это.


Никто не видит на какой домен вы заходите. Все что знает провайдер это только IP адрес на который вы обращаетесь.

Как "ловко" приравняли "никто не видит" и "провайдер не узнает". Если второе в теории ещё возможно, то первое — очевидное враньё. Третьи лица обязательно увидят весь маршрут вплоть до точки входа во владения владельца сайта. Этими третьими лицами не обязательно будет провайдер, в данном случае это будет тот кто управляет мультиплексором хостов на ip-адресе.


(касательно блокировок)

С нормальным SNI у вас была возможность показать провайдеру, что вы хотите посетить незаблокированный сайт при том что айпи его имеется в списках на проверку из-за ещё кого-то, а с шифрованным SNI вы от этой возможности отказываетесь — ну, ваше право, но какая от этого польза — непонятно совсем.

Третьи лица обязательно увидят весь маршрут вплоть до точки входа во владения владельца сайта. Этими третьими лицами не обязательно будет провайдер, в данном случае это будет тот кто управляет мультиплексором хостов на ip-адресе.


Задачи спрятать целевой домен от того, кто управляет мультиплексором хостов на IP адресе, не стоит. :-) Это, я думаю, хостинг-провайдер, который и так все знает про ваш сайт. Ему нет никакого смысла фильтровать пользователей вашего сайта. это не в его интересах.

Защитить свой сайт надо от того провайдера пользовательского доступа, который находится в РФ под контролем РКН и в силу этого вынужден осуществлять цензуру исходящих соединений.

С нормальным SNI у вас была возможность показать провайдеру, что вы хотите посетить незаблокированный сайт при том что айпи его имеется в списках на проверку из-за ещё кого-то, а с шифрованным SNI вы от этой возможности отказываетесь


Насколько я понимаю, сейчас провайдеры выгружают из РКН список блокировок и там указаны либо URL-и, либо IP адреса. Соответственно они блокируют что-то по именам, а что-то по адресам. Про то, что бывают записи вида «блокировать такой-то IP адрес, кроме тех, кто идет туда за сайтами отличными от [DNS-Name].com», я не слышал.
вагную сценарий:
в паблик интернете ESNI на IP из запрещенного пула будет дропаться. И появится рекомендация, что если вам нужно на легитимный ресурс, случайно попавший под блокировку, выключить ESNI в настройках браузера
в корпоративной среде ESNI будет выключен политиками, разлитыми через AD. Весь ESNI трафик, если такой окажется, будет дропаться. Хотя если в компании внедрена полноценная HTTPS инспекция, то в этом нет необходимости.
Люблю я такие прохладные истории. А теперь вспоминаем что сейчас век мобильных устройств. Все сидят в телефонах. Про политики сразу забываем. Про отключение в настройках так же забываем. 95% пользователей используют все по умолчанию. И если не работает сильно ругаются. Представить себе полезный и нужный по работе сайт использующий ESNI очень просто. Админ заблокировавший такое быстро оправится на ковер к начальству, а потом на мороз.

А еще больше я люблю вообще морозные истории про «полноценная HTTPS инспекция» ее никто никогда не видел, но все пугают.

Про блок по IP я написал. Никто ничего у себя включать/выключать не будет. Те кто на такое способны поставят vpn, остальные будут ругаться. Владельцы заблокированных до кучи сайтов буду судиться.
мобильных устройств и по работе — вещи немного несовместимые. Политики замечательно накатываются на рабочие ПК. А мобильные устройства пока плохо совместимы с корпоративно средой.
HTTPS инспекцию я не то, что видел, я её внедрял и не раз. Понимаете, в компаниях, которые заботятся о своей безопасности, принято проверять интернет-трафик. А так как в сети половина трафика — HTTPS, то его надо расшифровывать. Иначе, здравствуй Петя и убытки в миллионы зеленых.

Стремление к приватности понятно, но оно сталкивается с бизнесом и правительствами, которым нужна открытость.

По поводу того, что никто не будет включать-выключать — спорить бесполезно, жизнь покажет.
Поделитесь списком компаний, если имеется — ну, чтобы туда не ходить на собеседования.
По факту — никто не расшифровывает HTTPS с подменой посередине сейчас, обычно просто black/whitelist держат. В век BYOD было бы странно наблюдать иное.
Вы неверно мысль сформулировали.
Правильно будет так: Корпоративная среда (в вашем понимании этих слов) несовместима с современным миром. Без мобильных устройств сейчас и жизнь и работа просто невозможны.

И естественно никто ничего не расшифровывает и сертификаты не подменяет. Есть какое-то количество неадекватных фирм, я подозреваю что госы сплошь, которые могут такой фигней заниматься. С ними лучше не связываться. Если пришлось по проекту с ними общаться, то это обычно бывает так: Есть супер защищенная с митм сеть. А есть рядом стоящие ноутбуки на которых все и работают. Они смотрят в Интернет через обычный 4Г. И если что-то нужно в супер защищенной сети просто через флешку копируют.
И с почтой все забавно.
— Куда вам написать? Вот на этот адрес с визитки?
— Это рабочий вы лучше на него не пишите, он работает плохо. И не пропускает ничего. Пишите сюда на мой личный. И дают обычный gmail.

А чего спорить? История уже доказала что оно просто начнет работать у всех с какого-то момента. Как HTTPS. Очень долго говорили: Ну зачем? Большинству сайтов нечего шифровать. Это медленно, долго и сложно. Прошло время и теперь сайтов без HTTPS просто не осталось.
Вы не вполне понимаете корпоративную среду. :-)

Есть супер защищенная сеть без митм. Как, впрочем, и без доступа к Интернету вообще.
Есть стоящие рядом ноутбуки, с которых можно ходить в Интернет, но на которых уже стоит корневой сертификат, обеспечивающий митм при работе через корпоративную сеть. Флешки отключены на всех компах без исключения и пользователи никогда не имеют админского доступа.
Я не просто понимаю я с ней работал.

Тогда ставится рядом второй ноутбук с обычным 4Г.
Не работает вся эта схема с митм. Поставить можно. Внедрить можно. А работать не будет. В лаборатории без проблем, на реальных сетях не работает.

Сеть без интернета без проблем работает. Сценарий точно такой же. Рядом стоит ноутбук с 4Г. Только добавляется куча гемороя с обновлением всего и вся. Или пишутся смешные документы что мол у нас интернета нет и вообще все защищено и обновлений нам не надо. Живут такие документы до первого шифровальщика.

Ну не флешки, так какая-нибудь хитрая почта или шара в сети через которую все что угодно переслать можно. Проблема с невозможностью пересылки решается примерно через неделю-две после внедрения вот этого вот всего. Рабочий процесс встает и все быстро решается. Неофициально естественно.
Второй и даже третий ноут с 4Г поставить рядом можно. Проблема в том, что нет возможности с него что-либо переписать или другим путем передать на тот ноут, что в корпоративной сети. Не забывайте, админских прав ни у кого нет.

Все обновления (одобренные местными админами) работают с корпоративных серверов обновления, куда админы их выкладывают. Есть шара с «разрешенным» софтом, где можно найти практически что угодно.

Конечно, обходные пути всегда есть, но опять же, периодически запускается скрипт, который удаленно смотрит, что и на каком компе установлено и если что-то левое, то приходится объяснять, каким образом это туда попало.

Вообще, на мой взгляд, разумный подход. Бизнес-пользователи не обладают знаниями для того, чтобы подобные ограничения обойти. А IT-шники если что-то и обходят, то делают это достаточно разумно, чтобы не поломать безопасность.
А зачем админские права чтобы файликами кидаться? Есть аккуратненькая дырочка сквозь вот это вот все чтобы можно было передавать файлы. Без этого встает рабочий процесс. По регламенту работать невозможно.

Вот это я люблю. Одобренные местными админами! Как серьезно звучит. Как будто хоть один админ или даже целый отдел способен разобраться хотя бы в MS или Оракловых апдейтах. Не говоря уже обо всем остальном софте. Никто ни в чем естественно не разбирается. И даже не пытается разобраться. Хорошо если ставят достаточно быстро. Или не ставят и ловят шифровальщиков. В итоге дополнительный геморрой для админов на пустом месте.

Всем кому надо по работе, а это большая часть сотрудников уровнем выше дворника, приходят местные айтишники и все настраивают сами. И софт ставят и дырочку для передачи файлов делают. По негласному распоряжению руководства. Работать как-то надо.
Цензура в интернете сильно усложнится

Увеличатся штаты в Роскомнадзоре

UFO just landed and posted this here
Бесполезная штука.

DNS-запрос перед TLS-хендшейком раскрывает все карты — умные DPI без проблем сложат два и два.

Единственный способ это скрыть — DNS-over-TLS/HTTPS — то еще уродство, к сожалению. Чтобы сделать DNS-запрос нужно пройти TLS-хендшейк, проверить цепочку сертификатов и тп — это сильно повышает латентность и нагрузку. А если туда еще и HTTP внутрь запихали… Кэширование сессий помогает, но полностью проблему не решает.

С другой стороны хорошее решение этой проблемы в голову тоже не приходит. DNSCrypt вроде бы ничего, но он еще дальше от реальности чем вышеуказанные протоколы…
Кэширование сессий помогает, но полностью проблему не решает.
Keep-Alive TLS-соединение держится в течение нескольких десятков секунд.
Я не про кипэлайв, а про TLS Session Resumption, которая реализована через Session ID/Session Ticket.
Я это понял, но заметил, что соединение не устанавливается на каждый DNS-запрос, а живет еще минимум несколько десятков секунд после последнего.
Да, само собой, как и любом нормальном HTTP/1.1+ протоколе (если мы про DNS-over-HTTPS) он должен уметь держать коннект какое-то время. В DNS-over-TLS который по сути обертка поверх DNS-over-TCP тоже есть свои кипэлайвы, так что там по идее тоже вполне можно отправить несколько запросов не открывая новые коннекты.

Меня больше напрягает что все эти нововведения сидят в RFC-драфтах, а их активно тащат в продакшен разные отдельные компании. Договорились бы уже о единой реализации и топили за нее…
Sign up to leave a comment.

Articles