Leonid Evdokimov darkk

это достаточно просто реализовать в Knot Resolver и PowerDNS Recursor

FFAMax, а меня память подводит, или у тебя был готовый "умный резольвер", который выкидывал из ответа resource records с заблокированными адресами?

И до Санкт-Петербурга тоже добралось внедрение данной конструкции. Всё тот же редирект на r.analytic.press.

Mail.Ru Group

Кстати, а почему https://quantum-a.co/ не вспомнил? :-) Некоторый кусок инфраструктуры от них: редирект идёт на r.analytic.press, который 195.19.216.34, у которого admin-c: PM19270-RIPE, который Pavel Manyakin, у которого тёзка в R&D MegaLabs. Мегафон это всё же не совсем MRG. Так, на две трети :-)

а darkk — вот эти… это крайне регионозависимо

Там подобных историй про Ростелеком десятки и самые старые полуторагодовалой давности. И при том все эти истории про Сибирский макрорегион: Томск, Красноярск, Иркутск, Ангарск, Барнаул, Новосибирск...

Занятно ещё, что Kaspersky_Lab поучаствовали в истории в позитивном ключе, забанив один из доменов, использующихся для раздачи редиректов (не то чтоб это надолго помогло).

В публичных интернетах я такие упоминания ещё нашёл:

• 2018-09 https://modx.pro/development/16384
• 2018-09 https://qna.habr.com/q/565094
• 2018-10* https://searchengines.guru/showthread.php?t=1001505
• 2019-03 https://qna.habr.com/q/611320
• 2019-03 https://vk.com/x733337x?w=wall13108281_8116
• 2019-04 https://forum.kasperskyclub.ru/index.php?showtopic=62477
• 2019-04 https://forum.kasperskyclub.ru/index.php?showtopic=64215
• 2019-04 https://vk.com/wall-24720111_144558?w=wall-24720111_144558_r144815
• 2019-04 https://www.dwar.ru/info/forum/topic.php?id=688981
• 2019-05 https://community.kaspersky.com/kaspersky-internet-security-21/podozritelnaya-aktivnost-virtualbox-obnovlennogo-cherez-kis-1405
• 2019-08 https://fogalit.ru/sovety/rostelekom-podmenyaet-trafik/
• 2019-10 https://bitcointalk.org/index.php?topic=2254304.msg52862565#msg52862565
• 2019-12 https://packettotal.com/app/analysis?id=f0b10e249fa11ac05751398d894cc1d8&name=dns
• 2020-01 https://github.com/uBlockOrigin/uAssets/issues/6900
• 2020-01* https://2ch.hk/b/arch/2020-01-14/res/211528770.html
• 2020-01* https://qna.habr.com/q/701749
• 2020-01* https://www.yaplakal.com/forum32/topic2053730.html

*) уже упомянутые выше

Простите, я что-то упускаю один момент — а зачем судьи в идеальном обществе?

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

Продублирую комментарий из соседнего треда.

Я тут на всякий случай ещё раз обращу внимание на то, что:

• В дампе НЕТ ответов сервера.
• Слать любой трафик через :443 порт – классика обхода странных firewall'ов, там и OpenVPN вешают и MTProto. HTTP вешать мне кажется странным, но почему бы и нет.
• Эксперимент сам по себе поставлен довольно плохо: между проверкой ответов сервера по http на :443 и сбором трафика с :8800 IP-адреса съёмника прошли многие месяцы. Что-то могло и поменяться, например, вместе с закапыванием оскара.
• Даже если MRG и передаёт TLS/PFS-ключи, что предположить я могу (у Яндекса, например, их довольно шумно просили несколько месяцев тому назад), то для ФСБ передавать эти ключи на юридически провайдерское(!) оборудование может быть несколько странно с юридической же точки зрения. Всё же СОРМ "покупают", Леонид Волков пытался это как-то не очень успешно опротестовать с "народным провайдером". Я так говорю, т.к. задача терминации TLS "поближе к пользователю" на сервер в "провайдерской" стойке у некоторых CDN уж точно упиралась в вопрос, как при этом избежать утечки TLS-сертификата при НСД к оборудованию.
• http-трафика на :443 в общем объёме лога очень мало, ~0.05%. Например, от VK на :443 там за 5 дней два URL'а и на них перед этим была запись на аналогичный URL на :80. Это никак не бъётся с популярностью VK. Может быть это вообще какой-нибудь race-condition в обработчике и в логи пишется мусор.
• Вскользь упомянутые скрипты из пакетов МФИ-Софт, которые куда-то ходят за ключами и как-то обрабатывают TLS-трафик настолько странно выглядят, что мне это кажется скорее каким-то "наколеночным" отладочным инструментом для пятничной расшифровки по крону, чем "потоковым" средством обработки данных.

Т.е. эта история — это прикольный факт, но утверждать что-то про расшифровку https — это очень сильное допущение.

Чмоке, Артём! Приходи на 2600, LUG'овку и проч! :-)

Я тут на всякий случай ещё раз обращу внимание на то, что:

• В дампе НЕТ ответов сервера.
• Слать любой трафик через :443 порт – классика обхода странных firewall'ов, там и OpenVPN вешают и MTProto. HTTP вешать мне кажется странным, но почему бы и нет.
• Эксперимент сам по себе поставлен довольно плохо: между проверкой ответов сервера по http на :443 и сбором трафика с :8800 IP-адреса съёмника прошли многие месяцы. Что-то могло и поменяться, например, вместе с закапыванием оскара.
• Даже если MRG и передаёт TLS/PFS-ключи, что предположить я могу (у Яндекса, например, их довольно шумно просили несколько месяцев тому назад), то для ФСБ передавать эти ключи на юридически провайдерское(!) оборудование может быть несколько странно с юридической же точки зрения. Всё же СОРМ "покупают", Леонид Волков пытался это как-то не очень успешно опротестовать с "народным провайдером". Я так говорю, т.к. задача терминации TLS "поближе к пользователю" на сервер в "провайдерской" стойке у некоторых CDN уж точно упиралась в вопрос, как при этом избежать утечки TLS-сертификата при НСД к оборудованию.
• http-трафика на :443 в общем объёме лога очень мало, ~0.05%. Например, от VK на :443 там за 5 дней два URL'а и на них перед этим была запись на аналогичный URL на :80. Это никак не бъётся с популярностью VK. Может быть это вообще какой-нибудь race-condition в обработчике и в логи пишется мусор.
• Вскользь упомянутые скрипты из пакетов МФИ-Софт, которые куда-то ходят за ключами и как-то обрабатывают TLS-трафик настолько странно выглядят, что мне это кажется скорее каким-то "наколеночным" отладочным инструментом для пятничной расшифровки по крону, чем "потоковым" средством обработки данных.

Т.е. эта история — это прикольный факт, но утверждать что-то про расшифровку https — это очень сильное допущение.

Есть ещё гипотеза, что :8800 с кликстримом — это одна программа, а :1000 это уже статистика от МФИ-софт. Может это разные программы на одном железе, может это админ ISP NAT зачем-то сделал (адресов не хватало?).

Ну а статистика — это всё же не очень "управление ОРМ".

Во время доклада кто-то в зале использовал :)

Как и без SNI — ничего необычного не происходит.

На шифронаборы в сторону сервера можно посмотреть в pcap'е. Соответствующего ServerHello у меня нет.

начала исполнять код, копирующий весь транзитный трафик куда-то

Я хотел провести эксперимент, как отреагирует эта КазахГосМитмилка на самоподписанный сертификат facebook'а. Не успел :-(

На непатченного кальмара по ряду признаков не очень похоже. TLS-fingerprint от соединения ни на что известное не похож, да и TCP / IP заголовки тоже не оч.
Так что если и кальмар, то после глубокой переработки.

В данном измерении IP адрес был TCP-прокси не имеющей отношения к Facebook. Измерение было нужно для понимания, кэшируется ли как-то IP адрес после первого "попадания".

А есть какой-нибудь свежий источник про цифры? А то можно так же предположить, что по 443 идёт допусти 50% порнхаба и ютуба, и ещё немного QUIC. Ну и 5% каких-нибудь торрентов рядом. Тогда и нет никакой разницы :-)
В свежем посте в RIPE Labs я вообще не вижу p2p трафика в чарте (он только про web), поэтому цифры беру с потолка :-)

Серты, кажется, кэшируются — при повторных тестах тот же зонд видел тот же тест. А доменов ограниченное количество.

Не пробовал, времени не было :-(
Ну а потом, кажется, MITM то ли выключили, то ли просто пробник мой больше его не видел.

Зависит от количества трафика на :443. Поматчить 4 первых байта из client hello или два из TCP хэдера — на мой вкус не велика разница пока весь Client Hello в одном пакете идёт.

The mechanism was deprecated by the Google Chrome team in late 2017 because of its complexity and dangerous side-effects. Google recommends using the Expect-CT as a safer alternative.

— https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Без SNI пропускает, c SNI выдаёт обезопашеный серт. См. пробник 6308.

Нет, ближе к первому.
Запрос на нерелевантный IP с TCP Proxy DPI'ится в зависимости от SNI. На www.facebook.com приходит левый сертификат, а на darkk.net.ru нормальный (пока).

Это да. Но моё удивление не знало границ, когда я на 34c3 спрашивал Юлиуса:
— Слушайте, а как вы разворачиваете GSM-сеть на конфе? Ну это же регулиремые частоты, аэропорт рядом, тут 15 000 человек…
— Ну как. Мы же немцы. У нас есть немецкая бюрократия. И она работает. Если бы нам отказали в разрешении, мы бы попросту подали в суд.

Насколько я вижу, пара ключей CA используется для подписи промежуточного CA, а уже промежуточным подписан facebook. Я где-то ошибаюсь?

А почему вас удивляет, что корневой сертификат самоподписан? Это разве не стандартная схема?

Да, на chaos communication congress в Германии :-)

См. https://bugzilla.mozilla.org/show_bug.cgi?id=1567114#c21
Вы перепутали корневой и промежуточный сертификаты в цепочке.

Порой, да.

К слову о.
Ссылка раз.
Ссыла два.

На уделке вчера под ногами валялись "конверты" от SIM'ок десятками :-)

Его докерную сборку обновили не так давно.
По идее, сейчас должен уметь.

В Корее, говорят, заблокировали ESNI.

Про Yota — недавно был опубликован прекрасный костыль.
Который тоже пока работает :-)

Насколько я понимаю, tls-crypt-v2 меняет только процедуру генерации соответствующего ключа. Никакие дополнительные метаданные по сравнению с tls-crypt не шифрует.

TLS-handshake обфусцирует. Но там остаётся перманентный Session ID, опкоды и т.п. Для блокировки этого может быть достаточно.

1. зависит от провайдера, конечно же
2. злоумышленнику неплохо бы не быть в этой ситуации абонентом, т.к. при заключении договора с абонентом обычно известны его персданные :-)

В нём есть видео в кружочке же. :-)

Не то чтоб это было новостью :-)

Я напряженно ждал какой-нибудь политической пропаганды

"Мне нельзя в Бельдяжки". Уж извините, если разочаровал кого отсутствием агитпропа :-)

Конечно, может. И может как минимум ещё ограничивать число запросов в единицу времени.