Суть репозитория очень простая и очень неприятная. Автор не пытается «взломать Telegram» в лоб и не ломает криптографию MTProto. Репозиторий показывает куда более приземленную вещь. Если клиенту подменить адреса дата-центров и доверенный RSA-ключ, клиент начнет шифровать трафик не для Telegram, а для посредника. После этого посредник спокойно читает сообщения, сохраняет файлы и пересылает трафик дальше уже в настоящий Telegram.
Именно поэтому вокруг такого PoC нельзя спорить в стиле «но там же MTProto». Вопрос вообще не в названии протокола. Вопрос в том, кому именно клиент доверяет при первом рукопожатии. Если клиент доверяет уже не Telegram, а промежуточному узлу, весь красивый разговор про «шифрование на всем пути» теряет смысл. Шифрование остается, но начинает защищать канал до посредника, а не от посредника.
Что именно делает PoC без лишней драматургии
PoC воспроизводит схему, в которой клиент перестает ходить напрямую к настоящим DC Telegram. В README автор прямо показывает три ключевых шага. Первый шаг - заменить встроенные IP дата-центров на 127.0.0.1, то есть на локальный прокси. Второй шаг - заменить встроенный публичный RSA-ключ на новый ключ, сгенерированный скриптом. Третий шаг - зафиксировать настройки DC, чтобы клиент потом не откатил адреса через help.getConfig.
После такой подмены клиент подключается к локальному узлу на 127.0.0.1:443, а сам прокси уже отдельно ходит к реальным IP Telegram DC. В коде PoC для этого есть и локальный адрес прослушивания, и словарь с реальными адресами дата-центров. Дальше прокси фактически живет в двух сессиях сразу. Для клиента прокси играет роль «настоящего сервера». Для Telegram тот же прокси играет роль «обычного клиента».
Вот здесь и происходит главное. Клиент устанавливает защищенное соединение с посредником, потому что доверяет подмененному RSA-ключу. Потом посредник устанавливает уже другое соединение с настоящим Telegram. На выходе появляются две независимые криптографические сессии, а между ними лежит точка, которая видит данные в открытом виде.
Почему такой PoC опасен именно технически, а не только на словах
Сильная сторона проекта в том, что перед нами не теоретическая заметка и не набор обвинений без кода. В репозитории лежит рабочий скрипт mitm_dc.py, который не просто переправляет байты туда-сюда, а умеет разбирать смысл трафика. Скрипт загружает TL-схему из api.tl, распознает типы запросов и апдейтов и пишет в лог уже нормальные события уровня «отправка сообщения», «редактирование сообщения», «отправка медиа», «входящее сообщение».
Отдельно важен кусок с auth_key. В коде есть логика вывода ключей для шифрования и дешифрования MTProto-сообщений, а также кэширование клиентских и серверных ключей по отдельности. По сути посредник хранит обе стороны разговора под контролем. С технической точки зрения это и есть полноценный man-in-the-middle, а не декоративный «прокси для ускорения».
PoC также умеет собирать и сохранять загружаемые файлы. В коде есть буферизация частей upload.saveFilePart и upload.saveBigFilePart, определение типа файла по сигнатуре и сохранение результата в локальную папку. Для сообщений тоже нет магии. Скрипт разбирает messages.sendMessage, messages.editMessage, messages.sendMedia, updateShortMessage и updateShortChatMessage. То есть посредник видит не только факт соединения, а саму полезную нагрузку.
| Что показывает PoC | Почему это важно |
|---|---|
| Подмена IP дата-центров на локальный прокси | Клиент перестает говорить напрямую с Telegram и начинает говорить с посредником |
| Подмена встроенного RSA-ключа | Клиент доверяет уже не Telegram, а новой точке завершения рукопожатия |
| Две отдельные сессии шифрования | Посредник расшифровывает трафик на своей стороне и заново шифрует наружу |
| Разбор TL-схемы и логирование методов | Можно видеть уже не «пакеты», а нормальные сообщения, апдейты, контакты и медиа |
| Сохранение файлов локально | Речь идет не только о тексте, но и о документах, фото, видео и вложениях |
Почему фраза «но сообщения же все равно шифруются» здесь не спасает
Потому что шифрование без правильной точки доверия легко превращается в декорацию. В нормальной схеме Telegram-клиент должен доверять настоящим ключам и адресам инфраструктуры Telegram. Тогда внешний наблюдатель в сети не видит содержимое. В схеме из PoC клиент доверяет уже другому ключу и другому узлу. Значит, внешний наблюдатель действительно ничего не видит, но посредник внутри доверенной цепочки видит все.
Проще говоря, проблема не в том, что MTProto «не работает». Проблема в том, что MTProto в такой схеме начинает работать до неправильной конечной точки. А дальше посредник читает содержимое и пересылает его дальше уже в нормальный Telegram. Для пользователя снаружи картина почти не меняется. Чат открывается, сообщения уходят, файлы загружаются. Меняется только одно, но решающее обстоятельство: между пользователем и Telegram появляется узел, который может читать содержимое.
Самый важный вывод: риск касается не только пользователя Telega
Вот здесь многие недооценивают масштаб проблемы. Если один человек ставит клиент с такой моделью доверия, под удар попадает не только его собственная переписка. Под удар попадают все собеседники. Причина банальна. Когда собеседник пишет сообщение владельцу такого клиента, сообщение приходит в тот же чат и проходит через ту же промежуточную точку. Собеседник может пользоваться официальным Telegram, ничего не модифицировать и вообще не знать о существовании Telega, но его текст, файлы и контекст разговора все равно оказываются в зоне перехвата.
Риск не ограничивается текстом. В такой схеме посредник получает доступ к контактам, именам, идентификаторам, пересылаемым файлам, фотографиям, голосовым, заметкам в «Избранном» и другим данным, которые человек мог считать «своими». Для рабочей переписки картина еще хуже. Один сотрудник с сомнительным клиентом способен протащить через чужую инфраструктуру сообщения коллег, внутренние документы, сканы, доступы, чеки, номера телефонов и куски обсуждений, которые вообще не имели отношения к установке такого клиента.
Именно поэтому история опасна для всех. Такой клиент превращается в дырявую точку на границе доверия. Причем дырявую не только для владельца программы, но и для всех, кто с ним разговаривает.
Что PoC реально доказывает, а что не доказывает
Здесь полезно сохранять холодную голову. PoC очень хорошо доказывает техническую осуществимость атаки при подмене DC и доверенного RSA-ключа. PoC также показывает практический уровень доступа: чтение сообщений, разбор апдейтов, сохранение файлов, получение контактов. Для инженерного вывода этого уже достаточно. Если клиент устроен по такой модели, посредник получает содержимое.
Но PoC сам по себе не доказывает массовую эксплуатацию, объем уже собранных данных, конкретные внутренние процессы хранения, круг операторов доступа или масштаб реального использования на стороне сервиса. Для таких выводов нужны уже отдельные расследования, логи, утечки, внутренняя документация или независимый аудит. Подменять один тезис другим не стоит.
И все же главный практический вывод от такого ограничения не меняется. Для пользователя и его собеседников уже достаточно самого факта, что модель допускает прозрачный MITM с чтением содержимого. Когда речь идет о мессенджере, этого более чем достаточно, чтобы считать архитектуру опасной.
Почему такой PoC особенно неприятен для обычного человека
Потому что обычный человек почти никогда не замечает подобную подмену. В интерфейсе все выглядит штатно. Программа запускается, авторизация проходит, сообщения доставляются, медиа открываются. Никакого зрелищного «взлома» нет. Пользователь не видит момента, когда доверие уехало с Telegram на промежуточную инфраструктуру.
Еще неприятнее то, что люди постоянно используют Telegram как карманный сейф для всякой чепухи, которая потом неожиданно оказывается очень важной. Кто-то шлет себе в «Избранное» пароль, кто-то хранит фото документов, кто-то пересылает номер карты, кто-то обсуждает работу, кто-то отправляет файл от бухгалтера, кто-то делится личной перепиской. На бумаге человек может не делать «ничего секретного». В реальной жизни почти любой чат через пару месяцев превращается в архив приватных данных.
Практический вывод без истерики
telegaru-mitm-PoC ценен ровно тем, что показывает опасность на уровне кода, а не лозунгов. Смысл PoC можно свести к одной фразе. Если клиент подменяет точку доверия, посредник получает возможность читать все, что должно было идти только между клиентом и Telegram.
Для пользователя отсюда следует очень простой вывод. Сторонний клиент с собственной инфраструктурой, собственными ключами и непрозрачной моделью маршрутизации нельзя считать «тем же Telegram, только удобнее». В такой схеме меняется не оболочка, а сама граница доверия. А вместе с ней меняется и ответ на вопрос, кто может читать переписку.
Для всех остальных вывод еще жестче. Даже если вы лично пользуетесь только официальным Telegram, безопасность вашей переписки зависит не только от вас. Достаточно одного собеседника с клиентом, который заводит сообщения в промежуточную точку расшифровки, и приватность разговора уже перестает быть только вашим выбором.
Любые эксперименты с MITM, подменой ключей, перехватом трафика, разбором чужих сессий и модификацией клиентов допустимы только в законной исследовательской среде, где у вас есть прямое право на такие действия. Соблюдайте законодательство России и других стран. Нельзя использовать подобные материалы для доступа к чужой переписке, обхода ограничений, скрытого наблюдения или несанкционированного анализа данных.
FAQ
PoC ломает сам MTProto?
Нет. PoC не ломает алгоритмы MTProto. PoC подменяет точку доверия, из-за чего клиент шифрует трафик до посредника.
Почему риск касается и собеседников тоже?
Потому что их сообщения, файлы и контекст чата проходят через тот же клиент и ту же промежуточную точку, даже если сами собеседники используют официальный Telegram.
PoC доказывает, что кто-то уже массово читал все переписки?
Нет. PoC доказывает техническую возможность и рабочую механику такого перехвата. Масштаб реального применения требует отдельных доказательств.
Почему «у нас просто свои прокси» не выглядит безобидно?
Потому что обычный транспортный прокси не должен завершать доверенное рукопожатие на себе. Если узел получает свой доверенный ключ и свою точку завершения соединения, речь уже не про обычный прокси, а про посредника с доступом к содержимому.
