Это не совсем очевидный момент, во всяком случае для обывателей вроде меня.
Те ресурсы, доступ к которым "подлежит ограничению" — это непосредственно заблокированные ресурсы (и, как минимум, существует некая причина, а в идеале и решение суда, на их блокировку). Соответственно, все остальные ресурсы ("безобидиные сайты на Cloudflare") должны относиться к категории не подлежащих к ограничению?
Белые списки это кажется отдельная история, актуальная лишь в момент "угроз БПЛА" и всего такого. Допустим, что в конкретной ситуации они не применяются, и тогда какое будет основание блокировки легитимного трафика?
А так... я конечно не горю ложными надеждами, что после этого постановления интернет в России внезапно лучше работать начнет, но само по себе оно довольно интересное.
три легитимных основания для отключения ТСПУ оператором: [...] блокировка легального контента
Это что ж получается, теперь при необоснованных блокировках чего-бы то ни было (начиная от безобидных сайтов на Cloudflare, заканчивая играми) можно требовать у оператора отключить ТСПУ?
Хотелось бы верить, что это действительно может работать подобным образом. Хотя за последние годы складывается ощущение, что ТСПУ как раз и создавался, чтобы блокировать всё подряд и без причины просто с целью продвинуть отечественные сервисы, хостинги, etc. И с чего бы вдруг им отказываться от этой практики?
Не уверен насчет TLS, но в общем случае с TCP/UDP протоколами блокируются не только исходящие соединения. Кажется, DPI не особо волнует кто первым послал пакет, если соединение в целом установлено в "неправильную" сторону или имеет какие-то особые паттерны.
DPI-система видит HTTPS-трафик к Cloudflare. Заблокировать его значило бы сломать половину интернета.
Не думаю, что это кого-то (в РКН) останавливает. И без того уже многие легитимные ресурсы у некоторых фактически недоступны (либо доступны с нюансами навроде дикого замедления спустя некоторое время после установки соединения), в том числе и те, что были на Cloudflare...
Это значит, что прокси настраивается на низком уровне, в обход стандартных Android API, и весь трафик приложения заворачивается через сервера владельцев сервиса.
Автор преисполнился в реверс-инжиниринге через ChatGPT или что это за бред?
Нет, заворачивается не весь трафик. Нет, это не работает в "обход стандартных Android API". Нет, это безопасно, MTProxy сервер не видит вашей чувствительной информации. Это, черт возьми, механизм, введенный в официальные клиенты еще в 2018 году, когда телеграм в России блокировали.
Не защищаю продукт в сабже, но писать такие статьи – это какой-то позор. Не Hack Time, а Absolute Cinema, блят. И это я уже не говорю об аргументах про хттп заголовки тильды и наличии (о боже) трекеров...
Поскольку это всего лишь клиент-обертка над телеграмом, то и конкурирует он не с самим мессенжером, а с его официальным клиентом. И эта конкуренция может оказаться не очень уж и честной – когда сервера оригинального клиента начнут стремительно “устаревать”, то немалая часть людей найдет решение проблемы в таких вот клиентах.
исчезает конфиденциальность
А то есть сейчас она там присутствует? Использование VK Calls SDK в этом клиенте тоже ни на что не намекает?
Маленькая команда из 40 человек – при этом разработкой клиентов под каждую платформу занимается один, в лучшем случае два человека, которые не успевает исправлять все баги (некоторые не исправляются годами). Какой-то сомнительный повод для гордости получается...
Да и безопасность с шифрованием на уровне "да, мы храним все ваши сообщения, но никто не может их прочитать, честно-честно" тоже такое себе)
Уязвимость, о которой вы вспомнили – CVE-2020-36603 (если кому интересно поискать подробности). Но вообще проблемы с небезопасными драйверами уровня ядра есть не только у античитов игр, но даже у некоторых устройств…
Поэтому всякие важные-секретные ключи лучше хранить отдельно физически.
Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Уже не в первый раз натыкаюсь на подобные статьи на хабре, и даже не могу отрицать, что тема с анализом MAX довольно актуальная, нооо...
Где же настоящий анализ? Не "давайте посмотрим манифест", "ой я посмотрел и увидел много разрешений" или "джява-классы обфусцированы какой ужас", а уже настоящий разбор того, что этот мессенжер делает: как и когда взаимодействует с сервером и какие данные передает (хотя бы общее представление), для каких конкретных сценариев запрашиваются сомнительные разрешения (та же разблокировка экрана) и другие факты, по которым можно справедливее оценить степень доверия к этому приложению.
А то сейчас от таких разборов складывается лишь разочарование (не в обиду автору)
А в чем этот контроль проявляется для разработчиков (да и пользователей) macOS? Нет, ну вот правда интересно, как человеку, который с ней работает постоянно.
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Да, то, что проблема вызвана ТСПУ и действиями РКН не вызывает вопросов. Мы даже не в первый раз с таким сталкиваемся, но сейчас наиболее сильная волна таких «случайных» блокировок.
Самое печальное здесь то, что владельцы попавших под раздачу сервисов ничего не могут с этим поделать(
Владею проектом, большая часть инфраструктуры которого расположена на OVH. Начиная с 9 июня произошла значительная деградация подключений из РФ: после N килобайт данных соединения просто начинают терять пакеты. Причем это не полный дроп, изредка что-то таки долетает, из-за чего TCP подключения «зависают» в вечных retransmission, и даже определить достоверно, что подключение было «заблокировано» довольно тяжело.
Аналогичные вещи были замечены и с подключениями к другим хостинг-провайдерам. Кто-то жаловался на подключения к CloudFront, кто-то на CloudFlare.
А указанный вами сбой произошел позже, и не затронул, например, OVH. А вот проблемы были. И почему-то только лишь у российских пользователей.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика
Многие СМИ не упомянули, что аналогичное постановление уже существует и действует( я даже не знал об этом.
И получается, надеяться, что это постановление что-то изменит, вообще не имеет никакого смысла.
В остальном спасибо за важные замечания!
Это не совсем очевидный момент, во всяком случае для обывателей вроде меня.
Те ресурсы, доступ к которым "подлежит ограничению" — это непосредственно заблокированные ресурсы (и, как минимум, существует некая причина, а в идеале и решение суда, на их блокировку). Соответственно, все остальные ресурсы ("безобидиные сайты на Cloudflare") должны относиться к категории не подлежащих к ограничению?
Белые списки это кажется отдельная история, актуальная лишь в момент "угроз БПЛА" и всего такого. Допустим, что в конкретной ситуации они не применяются, и тогда какое будет основание блокировки легитимного трафика?
А так... я конечно не горю ложными надеждами, что после этого постановления интернет в России внезапно лучше работать начнет, но само по себе оно довольно интересное.
Это что ж получается, теперь при необоснованных блокировках чего-бы то ни было (начиная от безобидных сайтов на Cloudflare, заканчивая играми) можно требовать у оператора отключить ТСПУ?
Хотелось бы верить, что это действительно может работать подобным образом. Хотя за последние годы складывается ощущение, что ТСПУ как раз и создавался, чтобы блокировать всё подряд и без причины просто с целью продвинуть отечественные сервисы, хостинги, etc. И с чего бы вдруг им отказываться от этой практики?
Не уверен насчет TLS, но в общем случае с TCP/UDP протоколами блокируются не только исходящие соединения. Кажется, DPI не особо волнует кто первым послал пакет, если соединение в целом установлено в "неправильную" сторону или имеет какие-то особые паттерны.
Не думаю, что это кого-то (в РКН) останавливает. И без того уже многие легитимные ресурсы у некоторых фактически недоступны (либо доступны с нюансами навроде дикого замедления спустя некоторое время после установки соединения), в том числе и те, что были на Cloudflare...
Цена (~2000K$) на эти номера сейчас такая, что использовать их для ботов — идея не очень несостоятельная получается…
Автор преисполнился в реверс-инжиниринге через ChatGPT или что это за бред?
Функция, о которой идет речь, вот она: https://github.com/DrKLO/Telegram/blob/9cbf03332a5a68fce3e616852d7dc929022c8441/TMessagesProj/jni/tgnet/ConnectionsManager.cpp#L3703. Это функция в оригинальном коде Telegram, нужная чтобы задать настройки его же собственного механизма – MT Proxy.
Нет, заворачивается не весь трафик. Нет, это не работает в "обход стандартных Android API". Нет, это безопасно, MTProxy сервер не видит вашей чувствительной информации. Это, черт возьми, механизм, введенный в официальные клиенты еще в 2018 году, когда телеграм в России блокировали.
Не защищаю продукт в сабже, но писать такие статьи – это какой-то позор. Не Hack Time, а Absolute Cinema, блят. И это я уже не говорю об аргументах про хттп заголовки тильды и наличии (о боже) трекеров...
Поскольку это всего лишь клиент-обертка над телеграмом, то и конкурирует он не с самим мессенжером, а с его официальным клиентом. И эта конкуренция может оказаться не очень уж и честной – когда сервера оригинального клиента начнут стремительно “устаревать”, то немалая часть людей найдет решение проблемы в таких вот клиентах.
А то есть сейчас она там присутствует? Использование VK Calls SDK в этом клиенте тоже ни на что не намекает?
Маленькая команда из 40 человек – при этом разработкой клиентов под каждую платформу занимается один, в лучшем случае два человека, которые не успевает исправлять все баги (некоторые не исправляются годами). Какой-то сомнительный повод для гордости получается...
Да и безопасность с шифрованием на уровне "да, мы храним все ваши сообщения, но никто не может их прочитать, честно-честно" тоже такое себе)
Уязвимость, о которой вы вспомнили – CVE-2020-36603 (если кому интересно поискать подробности). Но вообще проблемы с небезопасными драйверами уровня ядра есть не только у античитов игр, но даже у некоторых устройств…
Поэтому всякие важные-секретные ключи лучше хранить отдельно физически.
Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Уже не в первый раз натыкаюсь на подобные статьи на хабре, и даже не могу отрицать, что тема с анализом MAX довольно актуальная, нооо...
Где же настоящий анализ? Не "давайте посмотрим манифест", "ой я посмотрел и увидел много разрешений" или "джява-классы обфусцированы какой ужас", а уже настоящий разбор того, что этот мессенжер делает: как и когда взаимодействует с сервером и какие данные передает (хотя бы общее представление), для каких конкретных сценариев запрашиваются сомнительные разрешения (та же разблокировка экрана) и другие факты, по которым можно справедливее оценить степень доверия к этому приложению.
А то сейчас от таких разборов складывается лишь разочарование (не в обиду автору)
А в чем этот контроль проявляется для разработчиков (да и пользователей) macOS? Нет, ну вот правда интересно, как человеку, который с ней работает постоянно.
Видны, указатель на функцию можно получить через findExportByName() (как у автора в посте)
Затем можно и вызвать через NativeFunction
Да, неточно выразился, но мысль была такая: ей всё равно
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Да, то, что проблема вызвана ТСПУ и действиями РКН не вызывает вопросов. Мы даже не в первый раз с таким сталкиваемся, но сейчас наиболее сильная волна таких «случайных» блокировок.
Самое печальное здесь то, что владельцы попавших под раздачу сервисов ничего не могут с этим поделать(
Это скорее просто интересное совпадение.
Владею проектом, большая часть инфраструктуры которого расположена на OVH. Начиная с 9 июня произошла значительная деградация подключений из РФ: после N килобайт данных соединения просто начинают терять пакеты. Причем это не полный дроп, изредка что-то таки долетает, из-за чего TCP подключения «зависают» в вечных retransmission, и даже определить достоверно, что подключение было «заблокировано» довольно тяжело.
Аналогичные вещи были замечены и с подключениями к другим хостинг-провайдерам. Кто-то жаловался на подключения к CloudFront, кто-то на CloudFlare.
А указанный вами сбой произошел позже, и не затронул, например, OVH. А вот проблемы были. И почему-то только лишь у российских пользователей.
Верно.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика