Кстати, а почему https://quantum-a.co/ не вспомнил? :-) Некоторый кусок инфраструктуры от них: редирект идёт на r.analytic.press, который 195.19.216.34, у которого admin-c: PM19270-RIPE, который Pavel Manyakin, у которого тёзка в R&D MegaLabs. Мегафон это всё же не совсем MRG. Так, на две трети :-)
Там подобных историй про Ростелеком десятки и самые старые полуторагодовалой давности. И при том все эти истории про Сибирский макрорегион: Томск, Красноярск, Иркутск, Ангарск, Барнаул, Новосибирск...
Занятно ещё, что Kaspersky_Lab поучаствовали в истории в позитивном ключе, забанив один из доменов, использующихся для раздачи редиректов (не то чтоб это надолго помогло).
В публичных интернетах я такие упоминания ещё нашёл:
Я тут на всякий случай ещё раз обращу внимание на то, что:
В дампе НЕТ ответов сервера.
Слать любой трафик через :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 зачем-то сделал (адресов не хватало?).
Ну а статистика — это всё же не очень "управление ОРМ".
На непатченного кальмара по ряду признаков не очень похоже. TLS-fingerprint от соединения ни на что известное не похож, да и TCP / IP заголовки тоже не оч.
Так что если и кальмар, то после глубокой переработки.
В данном измерении IP адрес был TCP-прокси не имеющей отношения к Facebook. Измерение было нужно для понимания, кэшируется ли как-то IP адрес после первого "попадания".
А есть какой-нибудь свежий источник про цифры? А то можно так же предположить, что по 443 идёт допусти 50% порнхаба и ютуба, и ещё немного QUIC. Ну и 5% каких-нибудь торрентов рядом. Тогда и нет никакой разницы :-)
В свежем посте в RIPE Labs я вообще не вижу p2p трафика в чарте (он только про web), поэтому цифры беру с потолка :-)
Зависит от количества трафика на :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.
Нет, ближе к первому.
Запрос на нерелевантный IP с TCP Proxy DPI'ится в зависимости от SNI. На www.facebook.com приходит левый сертификат, а на darkk.net.ru нормальный (пока).
Это да. Но моё удивление не знало границ, когда я на 34c3 спрашивал Юлиуса:
— Слушайте, а как вы разворачиваете GSM-сеть на конфе? Ну это же регулиремые частоты, аэропорт рядом, тут 15 000 человек…
— Ну как. Мы же немцы. У нас есть немецкая бюрократия. И она работает. Если бы нам отказали в разрешении, мы бы попросту подали в суд.
Насколько я понимаю, tls-crypt-v2 меняет только процедуру генерации соответствующего ключа. Никакие дополнительные метаданные по сравнению с tls-crypt не шифрует.