Comments 58
DNS-сервер провайдера сливает NS-записи о домене от владельца к себе. Утилита блокировки ресолвит домен, получает 100500 адресов, и по требованиям этой директивы, должна заблочить все эти IP
И все, кто за рогами и копытами — весело топают в роскомнадзор.
Как-то так.
по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нетуНе знаю, как у вас, меня ютюб принудительно перекидывает с http на https. И так делают многие крупные сервисы.
2. Владелец этого сайта вводит A-запись для своего домена, указывающую на youtube.com, например, 74.125.232.233
3. Провайдер блочит любой https-трафик на этот IP, потому что понять в нём ничего не может.
4. Юзер идёт по ссылке https://youtube.com/?video=grgrdghrghfdhfds
5. Получает блок по IP.
или пусть даже
4. Юзер идёт по ссылке http://youtube.com/
5. Провайдер понимает, что URL разрешённый и пропускает.
6. Гугл делает редирект на https://youtube.com/
7. Юзер получает блок по IP.
А вообще, недавно проскакивала статья, что клиент может писать в SNI что угодно, веб-сервера всё равно смотрят на заголовок Host в http-запросе под SSL. Ждём появления браузеров, которые в SNI будут писать легитимный или рандомный домен )))
а вот фигушки, делали подмену и блокировали весь ресурсЭто нужно для того, чтобы при приёме подменённого сертификата показать осмысленную заглушку, а не ошибку транспортного уровня. Так же делает ДОМ.RU
но зачем им это делать?Больше открывается разных сайтов — преимущество перед конкурентами.
недавно проскакивала статья, что клиент может писать в SNI что угодно, веб-сервера всё равно смотрят на заголовок Host в http-запросе под SSL
Ссылочкой не поделитесь? Что-то я себе слабо представляю, как оно работает.
Если несколько https-сайтов на одном ip — надо знать, какой сертификат выдавать до всяких Host.
Ссылочкой не поделитесь? Что-то я себе слабо представляю, как оно работает.Вот оно https://geektimes.ru/post/283998/
Если несколько https-сайтов на одном ip — надо знать, какой сертификат выдавать до всяких Host.Это работает и без SNI (Клиенты на Windows XP и Android 2.x не умеют SNI). В сервер загружаются сертификаты всех обслуживаемых им доменов и всё. С этим я сталкивался, администрируя Microsoft IIS, за другие сервера не скажу.
SNI придуман позже, чтобы можно было использовать балансировщики нагрузки, проксирующие SSL-соединения на другие хосты, не тратя время на расшифровку трафика.
В сервер загружаются сертификаты всех обслуживаемых им доменов и всё
И? А клиенту что отдавать? Все сразу, типа сам разберешься?
https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf
Появилась идея шифровать SNI. Те, кто пытался не фильтровать трафик хотя бы по домену, будут вынуждены вернуться к блокировкам по IP.
Ещё и http/2.0 грядёт, который в принципе хотят сделать шифрованным.
Провайдеров загоняют в угол ещё и штрафами: "Вводится новая статья 13.34 КоАП. Согласно ей, штраф на должностных лиц определен в размере от 3 тысяч до 5 тысяч. рублей, на лиц, осуществляющих предпринимательскую деятельность без образования юридического лица, — от 10 тысяч до 30 тысяч рублей; на юридических лиц — от 50 тысяч до 100 тысяч рублей." (с) rg.ru/2017/02/10/gosduma-vvela-shtrafy-dlia-provajderov-za-otkaz-blokirovki-sajtov.html
Блокировать будут самым надёжным способом, — по ip. Ну, кроме самых жирных операторов, готовых разориться на, сначала штрафы, а потом крутой DPI с огромной пропускной способностью. Причём, количество штрафов, на сколько знаю, тоже ограничено. Потом лицензию отнимут.
Либо терминировать весь https на входе. В пределе новые доверенные сертификаты можно распространять прямо с апдейтами локализированных версий операционных систем или какого-нибудь официального браузера. Certificate pinning, стараниями все того же энтерпрайза, уже давно толком ни где не работает по умолчанию.
Судя по тому, как развиваются события, вопрос «как?» уже не стоит. Сейчас главный вопрос «когда?».
Провайдеры тогда недоумевали «а чего это у нас доступ к реестру пропал?».
Кроме того, есть судебные решения, где суд учитывает какие IP в действительности были в реестре, а какие нет.
Решение суда есть в общем доступе?
Легко гуглится куча разрозненных тем по «filter-gw.transtelecom.net» (или «blacklist-gw.transtelecom.net»).
ТТК на магистральном уровне блочит рандомные не значащиеся в реестре IP (видно как раз потому, что детектят другие IP для заблоченных доменов, и кто-то троллит/или CDN).
В итоге не открываются рандомные сайты. Из последних крупных, что были замечены — сайты Uniquiti, служебные домены EVE Online, Ingress — правда все они на CDN сидят. Недавно пара IP Github.com была заблочена, со всеми вытекающими — гитхаб тупо не открывался несколько часов, но это было не сильно массово…
вот статья https://habrahabr.ru/post/272733/.
Минусы:
то что не умеет показывать заглушку, без подмены сертификата (ну это не критично, т.к. лучше блокировать 1 сайт, чем весь айпи).
Ну и ресурсоемкая, при большом кол-ве пользователей создается большое кол-во файловых дескрипторов, мне пришлось сделать tuning ядра в этом вопросе.
Надо чтобы днсы у клиентов и сквида были одинаковые, через политики АД или перенаправление днс запросов к себе, блокирование 53 порта всем клиентам во внешку вообще как варик.
Банится только домен из SNI, поэтому я составляю список url'ов с https и преобразовываю их в новый где присутствуют только домены, плюсую к ним список заблокированных доменов, сортирую, резолвлю все это нонстоп скриптами. Полученные айпи заливаются в циско, которое роутмапит их по порту 443 в сквид.
Хотя, можно еще 1 сервер специально для ревизора сделать, завернуть туда весь https трафик, чтобы не париться насчет динамических адресов.
Лечится простой записью в файервол (iptables). Вот тут все расписано: http://www.opennet.ru/tips/2999_iptables_block_tor.shtml
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Да и не факт, что прерывание отсылается.
Но, я предлагаю закончить теоретизирование на тему отмены запроса. Просто возьмите рецепт на который я сослался и попробуйте. Практика она такая — все теории на места расставляет очень быстро.
Если вы разрабатывали сервисы то должны знать:Плохой аргумент. TCP и прикладной сервис работают на разных уровнях. Стеку TCP абсолютно пофиг, насколько затратно прервать запрос для уровня выше. На его уровне совершенно беспроблемно закрыть соединение при получении RST.
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Просто возьмите рецепт на который я сослался и попробуйтеКак я узнаю, что провайдер отсылает RST серверу? Скорее всего, не отсылает, раз рецепт работает.
Вот мне пофигу до этого RST, для меня это не важно, для меня важно то, что я имею доступ к тому что мне нужно, а не к тому к чему мне дают доступ.
Поэтому я и советую от теорий перейти к практике, но вы меня не услышали. Жаль.
Это у вас теоретические измышления, насчёт трудоёмкости завершения запроса.
Или опыт в том, что фильтруя на клиенте RST, мы получаем соединение к заблокированным сайтам, а насчёт отправки RST серверу ничего не известно?
Если стек TCP/IP игнорит RST, зачем его блокировать на клиенте, он же проигнорируется…
Однако если для вас главное оставить последнее слово за собой, то так тому и быть. Можете дальше свои теории теоретизировать сколько вам угодно. Я только повторю — практика она точки над и расставляет гораздо лучше рассуждений и теорий.
Блокируй меня полностью — с любовью от «Ревизора»