HTTPS и блокировки с фильтрацией
Сейчас нередко приходится слышать, что тотальный переход сайтов на HTTPS помешает проведению “мягких блокировок” избранных сайтов провайдерами. Потому что в HTTPS, для инспектора трафика, не видны полные URL. Впрочем, тут можно напомнить про SNI – в рамках этой технологии, практически все современные браузеры, охватывающие, наверное, не менее 90% пользователей, передают имя хоста, с которым устанавливают TLS-соединение (HTTPS), в открытом виде:
То есть, хоть URL-ов и не видно, но адрес сайта, с которым пытается соединиться пользователь, системам инспекции трафика (DPI) доступен: блокируй – не хочу.
Вообще, полезно иметь в виду, что ни TLS, ни, тем более, HTTPS, не разрабатывались для преодоления систем фильтрации и блокирования доступа, так что как-то радикально повлиять на ситуацию они не могут. Хотя, конечно, проведение “тонкого блокирования” затрудняют. Но проблема не в этом. Да и “тонкое блокирование” – похоже, мало кому нужно.
А проблема со всей этой набирающей обороты “фильтрацией доступов” в том, что в реальность сетевых инженеров входят новые сложные инструменты, от которых зависит связность Сети. К сожалению, в этой же самой реальности, многие действующие специалисты (даже крупных провайдеров) не умеют правильно настроить более простые и хорошо изученные системы. А тут – непонятная добавка, какое-то блокирование. Так что, вне зависимости от того, наступит тотальное распространение HTTPS или нет, мы, в ближайшее время, встретимся с большим количеством “странных проблем” связности, когда большие кластеры интернет-ресурсов (вполне себе российских) не будут доступны для большого количества пользователей. Решать эти проблемы будет сложно, потому что мало кто будет понимать, что вообще происходит, и кто первый бросил снежок, вызвавший лавину. (Понимание – это отдельная история: сейчас хорошо видно, как это понимание покидает сообщество, а на смену ему приходят карго-культы.)
Адрес записки: https://dxdt.ru/2014/04/04/6722/
Похожие записки:
- Gofetch как уязвимость
- Пресертификаты в Certificate Transparency
- Наложенные сети Chrome для размещения сервисов
- TLS в виртуальных машинах и извлечение ключей хостингом
- Геоаналитика через "Яндекс"
- Экспериментальный сервер TLS 1.3 - отключение
- Статья Cloudflare про ECH/ESNI
- Централизация обновлений и CrowdStrike
- Поддержка STARTTLS сервисом audit.statdom.ru
- DNS-over-TLS на авторитативных серверах DNS
- Новые корневые сертификаты на audit.statdom.ru
Комментарии читателей блога: 3
1 <t> // 5th April 2014, 15:32 // Читатель RedElf написал:
А можно подробнее про “карго” – что конкретно имеется ввиду?
2 <t> // 5th April 2014, 18:19 // Александр Венедюхин:
Совсем конкретно я не стану писать, чтобы, как говорится, не показывать пальцем. У меня есть только общие слова: речь про обыкновенный карго-культ, о том, что, в рамках обеспечения функционирования сети, персонал всё больше просто выполняет некоторые действия, даже не стараясь понимать, зачем они нужны, что за ними стоит. Вот кто-то сказал, что периодически нужно запускать некий скрипт, он будет “блокировать адреса” – дальше его запускают, не думая о том, что, собственно, происходит, потому что нужно “запускать скрипт” и тогда “будет хорошо”. Я, конечно, несколько утрирую.
3 <t> // 7th April 2014, 13:14 // Читатель jno написал:
Практически буквально https://ru.wikipedia.org/wiki/%D0%9A%D1%83%D0%BB%D1%8C%D1%82_%D0%BA%D0%B0%D1%80%D0%B3%D0%BE (действительно, всё популярнее)
Кстати, то, что описал Александр – не “карго-культ”, как таковой, а просто ритуал :)