Comments 58
неопнял откуда паника.
В реестре сайт rogaikopita.sru допустим имеет адрес 1.1.1.300, dns говорит что у них уже адрес 1.1.1.400, в итоте тут говорится что проверка rogaikopita.sru будет осуществляться как по адресу 1.1.1.300 так и по адресу 1.1.1.400, а уж как блокировать, по домену, по урл или по ip, это уже указано в реестре.
Ничего собственно не изменилось, только раньше было указание проверять только трафик к ip из реестра, теперь проверяем весь трафик.
по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нету, значит блокируем отдельные урлы.
В реестре сайт rogaikopita.sru допустим имеет адрес 1.1.1.300, dns говорит что у них уже адрес 1.1.1.400, в итоте тут говорится что проверка rogaikopita.sru будет осуществляться как по адресу 1.1.1.300 так и по адресу 1.1.1.400, а уж как блокировать, по домену, по урл или по ip, это уже указано в реестре.
Ничего собственно не изменилось, только раньше было указание проверять только трафик к ip из реестра, теперь проверяем весь трафик.
по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нету, значит блокируем отдельные урлы.
Очень просто. Владелец rogaikopita.sru создаёт для своего домена множественные A-записи с IP-адресами ютюба, контакта, mail.ru и т.п. (а что — его домен, его DNS-сервер, пиши что хочешь).
DNS-сервер провайдера сливает NS-записи о домене от владельца к себе. Утилита блокировки ресолвит домен, получает 100500 адресов, и по требованиям этой директивы, должна заблочить все эти IP
DNS-сервер провайдера сливает NS-записи о домене от владельца к себе. Утилита блокировки ресолвит домен, получает 100500 адресов, и по требованиям этой директивы, должна заблочить все эти IP
Да оно и раньше так было, только сейчас комуто бумажки пришли. Все эти отмазки «по реестру сайт должен быть на другом ip» никогда не работали. Все мы понимаем, что сменить ip это дело 5 минут. Но дело в том, что от того что rogaikopita.sru поставит себе ip адрес гугла, гугел не заблокируют, провайдер все равно блочит по урлу. исключение https сайты, которые часто(а может редко) блочат по ip, но я о прецедентах такой подмены не слышал.
для блокировки ip там есть отдельный тип адреса, который с блоком по урлу не имеет ничего общего. В данном случае идет речь о блоке по урлу.
требованиям этой директивы, должна заблочить все эти IP
для блокировки ip там есть отдельный тип адреса, который с блоком по урлу не имеет ничего общего. В данном случае идет речь о блоке по урлу.
Сможете поработать с Google Search по http? У меня никак не получается, всё время переходит на https.
Кстати, а почему HTTPS препятствует блокировке одной отдельно взятой страницы? Объясните нубу, почему нельзя «забанить по URL» — неужели провайдер не способен отловить именно URL и заблокировать (редиректнуть на заглушку) именно его?
Потому что провайдер в запросе «https://test.example.com/megabombizspichek» видит только запрос на IP test.example.com, и если есть SNI (современные браузеры давно отправляют) то увидит «test.example.com». Всё остальное зашифровано. И отличить от запроса на «https://test.example.com/nobomb» невозможно.
UFO just landed and posted this here
Все еще проще. Оператор, видя, что доменное имя rogaikopita.sru валяется в списке на блокировку, добавляет в свой днс зону rogaikopita.sru с чем-нибудь вида * IN CNAME www.rkn.gov.ru.
И все, кто за рогами и копытами — весело топают в роскомнадзор.
Как-то так.
И все, кто за рогами и копытами — весело топают в роскомнадзор.
Как-то так.
по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нетуНе знаю, как у вас, меня ютюб принудительно перекидывает с http на https. И так делают многие крупные сервисы.
о мой бог. Как оно работает? я расскажу
в реестре у нас запись
http://youtube.com/?video=grgrdghrghfdhfds
Вариант http -> https
1)Устанавливаем подключение к 80 порту
2)Делаем запрос http://youtube.com/?video=grgrdghrghfdhfds
3)ютуб говорит нам, иди ка ты на https://youtube.com/?video=grgrdghrghfdhfds
так вот, провайдер блокирует на шаге 2, и блокирует(делает редирект на загрушку) еще на этапе http
вариант 2 hsts или как оно там, браузер автоматом все запросы http сразу же посылает на https
1)идем на https://youtube.com/?video=grgrdghrghfdhfds
в реестре такой ссылки нету, там только http -> ничего не блокируется, мы пользуемся ютубчиком.
Вот когда там появятся https сслыки на ютуб(а они появлялись, но быстро уходили оттуда) вот тогда и начнутся проблемы
в реестре у нас запись
http://youtube.com/?video=grgrdghrghfdhfds
Вариант http -> https
1)Устанавливаем подключение к 80 порту
2)Делаем запрос http://youtube.com/?video=grgrdghrghfdhfds
3)ютуб говорит нам, иди ка ты на https://youtube.com/?video=grgrdghrghfdhfds
так вот, провайдер блокирует на шаге 2, и блокирует(делает редирект на загрушку) еще на этапе http
вариант 2 hsts или как оно там, браузер автоматом все запросы http сразу же посылает на https
1)идем на https://youtube.com/?video=grgrdghrghfdhfds
в реестре такой ссылки нету, там только http -> ничего не блокируется, мы пользуемся ютубчиком.
Вот когда там появятся https сслыки на ютуб(а они появлялись, но быстро уходили оттуда) вот тогда и начнутся проблемы
1. Есть плохой сайт https://rogaikopita.sru
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.
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.
Да, если сайт в реестре по https, то такое возможно, я это отметил в своем коментарии выше. Многие(а может уже и нет) блочат такие сайты по ip. Но при установке ssl соединения браузер посылает client-hello пакет, в котором(вроде как не обзяательно) посылает server_name с которым он хочет соедениться, так вот, сейчас многие блочат ssl соединения именно по sni в clienthello.
Какие провайдеры реально учитывают SNI? Насколько я знаю, все блочат по IP простым правилом в firewall. Одно дело, когда в DPI идёт трафик маленького сайта-засранца, перенаправляемый в DPI по IP, а другое дело, если в него запулить весь трафик ютюба )))
А вообще, недавно проскакивала статья, что клиент может писать в SNI что угодно, веб-сервера всё равно смотрят на заголовок Host в http-запросе под SSL. Ждём появления браузеров, которые в SNI будут писать легитимный или рандомный домен )))
А вообще, недавно проскакивала статья, что клиент может писать в SNI что угодно, веб-сервера всё равно смотрят на заголовок Host в http-запросе под SSL. Ждём появления браузеров, которые в SNI будут писать легитимный или рандомный домен )))
Какие провайдеры реально учитывают SNI?
врятли ктото будет раскрывать эту информацию, но сам лично знаю таких. А вот ТТК некоторое время назад делал подмену сертификата, причем весьма странно, я думал «ну ладно, сертификат щас свой мне подсунут, но хотяб весь ресурс тогда не заблокируют, а только урл», а вот фигушки, делали подмену и блокировали весь ресурс.
Ждём появления браузеров, которые в SNI будут писать легитимный или рандомный домен
но зачем им это делать? наверно ж не с проста sni поле появилось и его используют.
а вот фигушки, делали подмену и блокировали весь ресурсЭто нужно для того, чтобы при приёме подменённого сертификата показать осмысленную заглушку, а не ошибку транспортного уровня. Так же делает ДОМ.RU
но зачем им это делать?Больше открывается разных сайтов — преимущество перед конкурентами.
UFO just landed and posted this here
недавно проскакивала статья, что клиент может писать в SNI что угодно, веб-сервера всё равно смотрят на заголовок Host в http-запросе под SSL
Ссылочкой не поделитесь? Что-то я себе слабо представляю, как оно работает.
Если несколько https-сайтов на одном ip — надо знать, какой сертификат выдавать до всяких Host.
Прошу прощения. Неправильно прочел ваш комент.
В client-hello можно писать всякую фигню только если один сайт на одном IP.
Ссылочкой не поделитесь? Что-то я себе слабо представляю, как оно работает.Вот оно 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 с огромной пропускной способностью. Причём, количество штрафов, на сколько знаю, тоже ограничено. Потом лицензию отнимут.
UFO just landed and posted this here
Можно поставить дополнительные условия с целью ограничить использовани https, а дальше web-сервисы уже сами подстроятся, чтобы не терять аудиторию. Особого технического резона использовать шифрование повсеместно нет, несколько лет тому назад Интернет прекрасно работал по http.
Либо терминировать весь https на входе. В пределе новые доверенные сертификаты можно распространять прямо с апдейтами локализированных версий операционных систем или какого-нибудь официального браузера. Certificate pinning, стараниями все того же энтерпрайза, уже давно толком ни где не работает по умолчанию.
Судя по тому, как развиваются события, вопрос «как?» уже не стоит. Сейчас главный вопрос «когда?».
Либо терминировать весь https на входе. В пределе новые доверенные сертификаты можно распространять прямо с апдейтами локализированных версий операционных систем или какого-нибудь официального браузера. Certificate pinning, стараниями все того же энтерпрайза, уже давно толком ни где не работает по умолчанию.
Судя по тому, как развиваются события, вопрос «как?» уже не стоит. Сейчас главный вопрос «когда?».
«по какой такой логике ютубчик должен быть заблочен? там есть https ссылки? нету, значит блокируем отдельные урлы. » чувааак… тебе лень посмотреть в каком формате ютуб даёт ссылки?)
UFO just landed and posted this here
Лучше повторить старую добрую историю, когда один заблокированный ресурс указал в качестве своего IP адрес сервера, с которого производится выгрузка реестра.
Провайдеры тогда недоумевали «а чего это у нас доступ к реестру пропал?».
Провайдеры тогда недоумевали «а чего это у нас доступ к реестру пропал?».
Кроме того, есть судебные решения, где суд учитывает какие IP в действительности были в реестре, а какие нет.
Решение суда есть в общем доступе?
Увы, в феврале-марте именно это и происходит у магистрала ТТК,
Легко гуглится куча разрозненных тем по «filter-gw.transtelecom.net» (или «blacklist-gw.transtelecom.net»).
ТТК на магистральном уровне блочит рандомные не значащиеся в реестре IP (видно как раз потому, что детектят другие IP для заблоченных доменов, и кто-то троллит/или CDN).
В итоге не открываются рандомные сайты. Из последних крупных, что были замечены — сайты Uniquiti, служебные домены EVE Online, Ingress — правда все они на CDN сидят. Недавно пара IP Github.com была заблочена, со всеми вытекающими — гитхаб тупо не открывался несколько часов, но это было не сильно массово…
Легко гуглится куча разрозненных тем по «filter-gw.transtelecom.net» (или «blacklist-gw.transtelecom.net»).
ТТК на магистральном уровне блочит рандомные не значащиеся в реестре IP (видно как раз потому, что детектят другие IP для заблоченных доменов, и кто-то троллит/или CDN).
В итоге не открываются рандомные сайты. Из последних крупных, что были замечены — сайты Uniquiti, служебные домены EVE Online, Ingress — правда все они на CDN сидят. Недавно пара IP Github.com была заблочена, со всеми вытекающими — гитхаб тупо не открывался несколько часов, но это было не сильно массово…
Ну так пополнять бюджет хоть на сколько-то надо — вот и повод нашёлся. Такое в каждой сфере периодически проскакивает.
Есть уточнение по 3-му пункту. squid умеет прозрачно блочить https домены, не трогая остальные домены на cdn
вот статья https://habrahabr.ru/post/272733/.
Минусы:
то что не умеет показывать заглушку, без подмены сертификата (ну это не критично, т.к. лучше блокировать 1 сайт, чем весь айпи).
Ну и ресурсоемкая, при большом кол-ве пользователей создается большое кол-во файловых дескрипторов, мне пришлось сделать tuning ядра в этом вопросе.
Надо чтобы днсы у клиентов и сквида были одинаковые, через политики АД или перенаправление днс запросов к себе, блокирование 53 порта всем клиентам во внешку вообще как варик.
Банится только домен из SNI, поэтому я составляю список url'ов с https и преобразовываю их в новый где присутствуют только домены, плюсую к ним список заблокированных доменов, сортирую, резолвлю все это нонстоп скриптами. Полученные айпи заливаются в циско, которое роутмапит их по порту 443 в сквид.
Хотя, можно еще 1 сервер специально для ревизора сделать, завернуть туда весь https трафик, чтобы не париться насчет динамических адресов.
вот статья 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
Лечится простой записью в файервол (iptables). Вот тут все расписано: http://www.opennet.ru/tips/2999_iptables_block_tor.shtml
проблема в том, современные системы посылают пакеты в обе стороны, клиенту на http_redirect, серверу tcp с R флагом. Так что такой записью ты просто убьешь свою переадресацию, сайт не заработает.
Только вот сервер имеет право на tcp c R флагом не реагировать, что большинство и делают. Так что, с одним большим оператором — все прекрасно работает: проверено на куче сайтов из списка блокировки.
Это как не реагировать, если клиент хочет прервать соединение? Зачем серверу держать в памяти лишние завершённые соединения, ресурсы некуда девать?
Если вы разрабатывали сервисы то должны знать:
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Да и не факт, что прерывание отсылается.
Но, я предлагаю закончить теоретизирование на тему отмены запроса. Просто возьмите рецепт на который я сослался и попробуйте. Практика она такая — все теории на места расставляет очень быстро.
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Да и не факт, что прерывание отсылается.
Но, я предлагаю закончить теоретизирование на тему отмены запроса. Просто возьмите рецепт на который я сослался и попробуйте. Практика она такая — все теории на места расставляет очень быстро.
Если вы разрабатывали сервисы то должны знать:Плохой аргумент. TCP и прикладной сервис работают на разных уровнях. Стеку TCP абсолютно пофиг, насколько затратно прервать запрос для уровня выше. На его уровне совершенно беспроблемно закрыть соединение при получении RST.
Прервать выполнение запроса иногда бывает затратнее чем доделать все до конца (т.е. игнорировать прерывание).
Просто возьмите рецепт на который я сослался и попробуйтеКак я узнаю, что провайдер отсылает RST серверу? Скорее всего, не отсылает, раз рецепт работает.
А вам нужно знать отсылается RST или нужен доступ?
Вот мне пофигу до этого RST, для меня это не важно, для меня важно то, что я имею доступ к тому что мне нужно, а не к тому к чему мне дают доступ.
Поэтому я и советую от теорий перейти к практике, но вы меня не услышали. Жаль.
Вот мне пофигу до этого RST, для меня это не важно, для меня важно то, что я имею доступ к тому что мне нужно, а не к тому к чему мне дают доступ.
Поэтому я и советую от теорий перейти к практике, но вы меня не услышали. Жаль.
Доступ у меня и так есть.
Это у вас теоретические измышления, насчёт трудоёмкости завершения запроса.
Это у вас теоретические измышления, насчёт трудоёмкости завершения запроса.
Спасибо кэп, что открыли мне глаза на то, что мой опыт нужно выкинуть на помойку как теоретические измышления. :)
Ваш опыт в том, что сервер не реагирует на RST? (кстати, за это отвечает ОС, а не веб-сервер — какая ОС имеет такое поведение в TCP/IP стеке?).
Или опыт в том, что фильтруя на клиенте RST, мы получаем соединение к заблокированным сайтам, а насчёт отправки RST серверу ничего не известно?
Если стек TCP/IP игнорит RST, зачем его блокировать на клиенте, он же проигнорируется…
Или опыт в том, что фильтруя на клиенте RST, мы получаем соединение к заблокированным сайтам, а насчёт отправки RST серверу ничего не известно?
Если стек TCP/IP игнорит RST, зачем его блокировать на клиенте, он же проигнорируется…
Вы для начала определитесь куда RST идет на сервер или на клиента и как его блокировать на клиенте, если оно идет на сервер. Вы что-то уже совсем запутались похоже…
Однако если для вас главное оставить последнее слово за собой, то так тому и быть. Можете дальше свои теории теоретизировать сколько вам угодно. Я только повторю — практика она точки над и расставляет гораздо лучше рассуждений и теорий.
Однако если для вас главное оставить последнее слово за собой, то так тому и быть. Можете дальше свои теории теоретизировать сколько вам угодно. Я только повторю — практика она точки над и расставляет гораздо лучше рассуждений и теорий.
Как раз по этому причине Equestria Daily не работает. Все из-за того, что на этом же айпишнике находились нехорошие вещи. А провайдер, вместо того, чтобы показывать свою стандартную заглушку, дропает пакеты
Наверное не совсем правильно употреблять слова «логика» и «Роскомназдор» (на самом деле <впишите любое название госструктуры>) в одном месте, если только это не выражения вроде «логика отсутствует».
Sign up to leave a comment.
Блокируй меня полностью — с любовью от «Ревизора»