Pull to refresh
165
0
Leonid Evdokimov @darkk

Пользователь

Send message

Ну это не понятно, но, думаю, РосКомСвободе может быть интересно попарсить этот список, чтоб уточнить свои оценки collateral damage от пошареных IP-адресов в выгрузке РосКомНадзора.


Также, я предполагаю, они такой список доменов могли получить и до сегодняшнего дня :-)

вы смелый человек

В ответ могу лишь повторить слова президента: кому суждено быть повешенным, тот не утонет. Большей определённости от будущего ждать сложно.


из-под трёх слоёв анонимности

Надеюсь, что, в случае капитальной аварии магистральных провайдеров, инициатора будут пытаться искать компетентные органы, а не массовые преследователи "политических заключённых".


да минует вас чаша сия

Спасибо.

проблема с переполнением ipv4 маршрутов на старых цисках

В точности. Только 3-4 года назад рост размера таблицы был постепенный и органичный. А во что может вылиться история с реестром — не очень понятно. Понятно только что /32 маршруты таки протекают из DNS в таблицы.

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

user agent в запросах

Какая-то часть запросов наверняка от Ревизоров, да. Если кто-то хочет погрепать логи, могу отгрузить access.log чтоб посмотреть на HTTP трафик приходящий параллельно с DNS. А про какой user-agent в DNS-запросах речь? :)

какие последствия

При переполнении TCAM маршрутизатор может начать обрабатывать трафик не на data plane, а на control plane. Это может привести к 100%ной загрузке CPU маршрутизатора и потери части трафика (возможно, большой). Перегрузка CPU теоретически может привести к проблемам с пирингом и выпадением этого маршрутизатора из сети. Учитывая, что магистральные провайдеры как РЕТН обрабатывают большую часть трафика, трафик пойдёт другим маршрутом: либо через другой маршрутизатор (перегрузив, возможно, и его), либо через другого провайдера (где каналы тоже не бесконечны). Что может теоретически привести к каскадному распространению аварии. Т.е., грубо говоря, в России внезапно выключится Интернет.


Я не знаю цифр про запас по объему таблиц маршрутизации, про запас по каналам, есть ли автоматически включаемый fallback вида "при отказе фильтра пустить всё напрямую", поэтому сценарий "грянет" считаю гипотетически возможным. Статью написал для того, чтоб обратить внимание на потенциальную мину в "критической инфраструктуре", подложенную РКН :-)

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

А лишние биткоины лучше отправить семье Димы Богатова, арестованного за слова Айрата Баширова оператора выходного узла Tor, чем интернет в РФ ломать. :-)
Транстелеком сначала начал проксировать все запросы к заблокированным сайтам в транзите

Мне больше интересно, что произойдёт с подобными фильтрами на транзите, если количество IP-адресов в которые резольвятся доменные имена из реестра подберётся к размерам TCAM на маршрутизаторах. Если я верно понимаю lg, то домены в роуты /32 резольвит не только ТТК, но и, например, Ростелеком.

Если каждый хулиганский домен отдаст по 4000 рандомных устаревших IPv4 адресов и по 2300 современных IP (примерно столько помещается в DNS-ответ максимального размера), то для выжирания TCAM с 512к записями, если я не обсчитался, достаточно будет примерно 60 доменов. У одних только граней.ру их в 10 раз больше. Disclaimer: *.rnd.darkk.net.ru. в реестре нет, это я поведение резольверов с большими ответами тестирую в рамках OONI и трафик на этот домен логируется.

И ежемесячную выписку по счёту несколько лихо слать открытым текстом (по SMTP, без TLS, со всеми финансовыми транзакциями вместо ссылки на залогиновый документ).

Почему не поможет? По крайней мере на android работает.

Мне, кстати, интересно, станут ли каике-то другие CA использовать certbot для DV сертификатов. Кажется, я про какие-то такие планы слышал, но сейчас за пару минут найти ссылок не смог.
Ну не знаю, как-то не шифропанково =) Лучше уж тогда самоподписанный, чем такой сертификат в trust store добавлять =)
И, да, ругается браузер даже не на доверенность сертификата, а на SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED. Может там где подразломанные MD5 или SHA1 в цепочке. Не знаю.
Собственно, да, для меня он лучше только тем, что браузер на него по-умолчанию «не ругается». Насколько эффективна вся эта история с аудитом для включения в списки браузеров мне не очень понятно, но, мне кажется, пользы в этом больше, чем у cacert при той же «стоимости». Возни там не много :-)

Ещё letsencrypt делают интересную вещь — заставляют каждые три месяца перевыпускать сертификат, что даёт некоторое подобие (im-)perfect forward secrecy «для бедных», т.е. для тех клиентов, которые не умеют PFS шифры.

Если хочется сохранить свойство TOFU, которое даёт самоподписанный сертификат, то можно взять HPKP. Таким образом браузер пользователя будет в первый заход на сайт использовать отношение доверя «корпорации», а во второй уже полагаться только на доверие администратору сайта.
Кстати, lists.cypherpunks.ru uses an invalid security certificate. The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure.

Да поможет тебе Let's encrypt.
Совершенно не обязательно. Некоторые провайдеры пишут netflow-логи до и после NAT. А потом в чатиках, посвящённых машинному обучению, спрашивают, как эту бигдату обрабатывать, чтоб на запросы органов отвечать :)

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity