Мессенджер и удаление сообщений
Занятно читать массовые рекомендации про “срочно удалите все сообщения из переписок в мессенджере” в свете новостей о популярном мессенджере Telegram.
Дело в том, что даже если удалённые на устройстве-клиенте сообщения действительно удалятся и на серверной стороне (если они там были, да), в том числе, из всех “бэкапов” разных уровней, то это вовсе не означает, что удалится и соответствующий трафик из сетевых дампов.
Telegram – центральный мессенджер, это означает, что нетрудно определить узлы, через которые проходят все сообщения. Даже если сервер сообщения удалил (не факт, но ладно), то соответствующий трафик, при необходимости, без проблем, в пассивном режиме, сохраняется на стороне подключения каждого дата-центра, ну, это как минимум. Каких-то уведомлений “арендатора” для того, чтобы поставить “сплиттер” в нужном месте, не требуется. Все сообщения восстанавливаются из трафика, если имеются нужные ключи.
(Дополнение: да, естественно, в удалении сообщений с устройства может быть польза, понятно; речь о другом; о том, что нужно использовать правильную “модель угроз”; удаление сообщений в приложении на устройстве – это удаление сообщений в приложении на устройстве, не более того: сообщения-то и с устройства при этом могут не удалиться, что уж говорить про прочие хранилища.)
Адрес записки: https://dxdt.ru/2024/08/25/13731/
Похожие записки:
- Наложенные сети Google и браузеры в будущем
- STARTTLS и SMTP
- Централизация обновлений и CrowdStrike
- Влияние систем ИИ на процессы в мире
- DNS-over-TLS как инструмент трансляции доверия в DNSSEC
- Взлом Twitter и влияние на офлайн
- "Почти что коллизия" и хеш-функции
- Утечки данных YubiKey/Infineon
- Подмена хостнейма WHOIS-сервиса .MOBI
- Реплика: программные "демультиплексоры" протоколов уровня приложений
- Кубиты от IBM
Комментарии читателей блога: 2
1. 25th August 2024, 17:33 // Читатель silmor_senedlen написал:
С первым тезисом(пол удаление истории чатов) согласен: тут уж как повезёт – без публичных независимых аудитов инфраструктуры этого знать просто невозможно.
На счёт второго тезиса(про сбор трафика на транзите с последующей расшифровкой при наличии “ключа”): тут стоило бы подробнее прояснить, какой именно “ключи” подразумевается.
Ведь если мы говорим о шифровании на уровне MTProto, то он, по заявлениям, давно поддерживает PFS (Perfect Forward Secrecy), что как раз и нацелено на защиту трафика от последующей расшифровки, так как для шифрования не используется постоянный/статичный ключ, а временный (для каждой сессии).
В таком случае для того чтобы иметь возможность расшифровать трафик, необходимо на стороне клиента или сервера намерено записывать все сессионные ключи PFS, которые в обычном случае существуют только в оперативной памяти.
Если это делается на уровне серверов Telegram на постоянной основе, то это конечно явный признак злого умысла, и в случае выявления подобного факта, вся декларируемая политика Telegram рухнет в одночасье.
2. 25th August 2024, 18:12 // Александр Венедюхин:
Ключи – да, имеются в виду ключи, относящиеся и к TLS, и к самим сообщениям, весь набор. Предполагается, что они “каким-то образом” становятся известны третьей стороне. Если я верно понял текущую ситуацию массового пользователя Telegram, то там “передача ключей” предполагается по условиям задачи, и это должны быть универсальные ключи (ну, где-то они должны быть, раз речь про удаление сообщений как “меру защиты от перехвата” вообще зашла).
Кстати, вот в общем, так сказать, случае, ключи от внутренних протоколов не обязательно явно сохранять – ключи могут вычисляться из состояния генератора псевдослучайных чисел, предположим, а состояние генератора – может быть видно по TLS, предположим. Ну или ещё как-то станут “утекать” ключи. Но могут и не утекать, конечно.
Написать комментарий