Я тут на всякий случай ещё раз обращу внимание на то, что:
В дампе НЕТ ответов сервера.
Слать любой трафик через :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 человек…
— Ну как. Мы же немцы. У нас есть немецкая бюрократия. И она работает. Если бы нам отказали в разрешении, мы бы попросту подали в суд.
Кстати, говорят, что электросудорожная терапия и по сей день применяется как один из методов лечения, если остальные не помогли.
Продублирую комментарий из соседнего треда.
Я тут на всякий случай ещё раз обращу внимание на то, что:
:443порт – классика обхода странных firewall'ов, там и OpenVPN вешают и MTProto. HTTP вешать мне кажется странным, но почему бы и нет.:443и сбором трафика с:8800IP-адреса съёмника прошли многие месяцы. Что-то могло и поменяться, например, вместе с закапыванием оскара.:443в общем объёме лога очень мало, ~0.05%. Например, от VK на:443там за 5 дней два URL'а и на них перед этим была запись на аналогичный URL на:80. Это никак не бъётся с популярностью VK. Может быть это вообще какой-нибудь race-condition в обработчике и в логи пишется мусор.Т.е. эта история — это прикольный факт, но утверждать что-то про расшифровку https — это очень сильное допущение.
Чмоке, Артём! Приходи на 2600, LUG'овку и проч! :-)
Я тут на всякий случай ещё раз обращу внимание на то, что:
:443порт – классика обхода странных firewall'ов, там и OpenVPN вешают и MTProto. HTTP вешать мне кажется странным, но почему бы и нет.:443и сбором трафика с:8800IP-адреса съёмника прошли многие месяцы. Что-то могло и поменяться, например, вместе с закапыванием оскара.:443в общем объёме лога очень мало, ~0.05%. Например, от VK на:443там за 5 дней два URL'а и на них перед этим была запись на аналогичный URL на:80. Это никак не бъётся с популярностью VK. Может быть это вообще какой-нибудь race-condition в обработчике и в логи пишется мусор.Т.е. эта история — это прикольный факт, но утверждать что-то про расшифровку 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 в одном пакете идёт.
Без SNI пропускает, c SNI выдаёт обезопашеный серт. См. пробник 6308.
Нет, ближе к первому.
Запрос на нерелевантный IP с TCP Proxy DPI'ится в зависимости от SNI. На
www.facebook.comприходит левый сертификат, а наdarkk.net.ruнормальный (пока).Это да. Но моё удивление не знало границ, когда я на 34c3 спрашивал Юлиуса:
— Слушайте, а как вы разворачиваете GSM-сеть на конфе? Ну это же регулиремые частоты, аэропорт рядом, тут 15 000 человек…
— Ну как. Мы же немцы. У нас есть немецкая бюрократия. И она работает. Если бы нам отказали в разрешении, мы бы попросту подали в суд.
Насколько я вижу, пара ключей CA используется для подписи промежуточного CA, а уже промежуточным подписан facebook. Я где-то ошибаюсь?
А почему вас удивляет, что корневой сертификат самоподписан? Это разве не стандартная схема?