Примечание: это перевод подробного технического отчета специалиста по инфобезопасности Михала Возняка. Краткое изложение проблемы протокола MTProto и расследование про сетевую инфраструктуру Telegram, ее владельцев и связей, можно прочитать в статье IStories*
Многие люди, занимающиеся информационной безопасностью, включая меня, давно считают Telegram подозрительным и ненадежным. Теперь, основываясь на выводах, опубликованных расследовательским журналистским изданием IStories и моем собственном анализе перехватов пакетов из Telegram для Android и протокола Telegram, описанного ниже, я считаю Telegram неотличимым от ханипота для слежки.
Telegram генерирует долгосрочный идентификатор, называемыйauth_key_id, на каждом клиентском устройстве. Этот идентификатор не меняется в зависимости от того, откуда подключается клиент.
Текущий протокол Telegram, MTProto 2, требует, чтобы этот долгосрочный идентификатор передавался открытым текстом или, в лучшем случае, простенько обфусцирован, по крайней мере, для некоторых зашифрованных сообщений, отправляемых через сеть. Когда используется perfect forward secrecy, временныеauth_key_idгенерируются каждые 24 часа или около того и используются вместо долгосрочных, но все еще добавляются открытым текстом к зашифрованным сообщениям. Это позволяет любому, у кого есть возможность анализировать трафик сети и желание сделать это, идентифицировать трафик, исходящий с определенного пользовательского устройства.
Это удивительное и совершенно ненужной решение в дизайне протокола, которого нет ни в Signal, ни в WhatsApp.
Издание IStories обнаружило доказательства того, что все сетевые коммуникации в инфраструктуру Telegram и из нее проходят через компанию, связанную со спецслужбами. Это обеспечило бы возможность анализировать передаваемые по сети данные, которая в сочетании с передаваемым в нешифрованныом видеauth_key_idпозволила бы идентифицировать трафик, исходящий от определенных пользователей, по всему миру.
Другими словами, то, что на протяжении многих лет казалось странностью в дизайне протокола, теперь больше похоже на преднамеренное решение облегчить глобальное наблюдение за всеми пользователями Telegram со стороны государства, одновременно скрывая роль компании, предоставляющую Telegram серверную и сетевую инфраструктуру.
Два решения, принятые Telegram (выбор поставщика инфраструктуры, который сотрудничает с российскими спецслужбами, и прикрепление идентификатора устройства в открытом виде к зашифрованным сообщениям), вместе взятые, значительно усиливают возможности по слежке за пользователями, чем любое из этих решений по отдельности.
Неважно, были ли эти решения приняты намеренно или случайно. Telegram неотличим от ханипота.
Предыстория: подозрительный Telegram
Годами Telegram казался подозрительным и вел себя подозрительно с точки зрения многих людей, работающих в сфере информационной безопасности. Они «развернули собственную криптографию» ("enrolled their own crypto" - то что во всех учебниках по криптографии рекомендуется не делать), MTProto.
Они плохо отреагировали на обоснованную критику в свой адрес. Павел Дуров лично продолжал атаковать и оговаривать конкурентов с полностью сквозным шифрованием, таких как Signal — причем совершенно необоснованным образом.
Всякий раз, когда кто-то пристально смотрел на протокол MTProto (первой версии), они задумчиво чесали голову. Протокол казался странным, но никто не мог доказать, что он небезопасен. Пока, наконец, кто-то не обнаружил ошибку протокола, которая была (как выразился один блоггер) «настолько близка к бэкдору, насколько они когда-либо видели», потенциально позволяя Telegram расшифровывать сквозные зашифрованные сообщения.
Telegram исправил проблему, а затем выпустил вторую версию своего собственного протокола, MTProto 2. Опять же, когда люди начали присматриваться к нему, казалось, что с ним что-то не то, но до сих пор никто не смог доказать, что в протоколе есть какая-то проблема с шифрованием.
Ранее я сказал «конкуренты с полностью сквозным шифрованием» — это потому, что большая часть общения через Telegram происходит без сквозного шифрование, независимо от того, что неустанно предлагают собственные рекламные материалы Telegram. Только так называемые секретные чаты имеют сквозное шифрование, но то, как сделали UI/UX для них делает их неудобными и непрактичными в использовании. Пользовательский интерфейс Telegram разработан таким образом, что он в основном препятствует использованию секретных чатов. Сквозное шифрование также вообще недоступно для групп и каналов. Я немного углубился в это здесь.
Согласно информации, найденной журналистами IStories*, в 2018 году 98% всей коммуникации в Telegram не было зашифровано сквозным шифрованием. Насколько я могу судить, сегодня ситуация выглядит не сильно лучше.
В то же время маркетинг Telegram в значительной степени опирается на утверждение, что Telegram «надежно зашифрован». Трудно рассматривать это как что-то иное, кроме как введение в заблуждение. Это подвергает людей, использующих сервис, опасности, заставляя их думать, что они общаются с использованием сквозного шифрования, когда это не так — что я сам видел в контексте людей, выполняющих конфиденциальную работу.
MTProto 2 от и до
Согласно собственной документации Telegram, все клиент-серверное общение в системе происходит с использованием MTProto 2. Сообщения, которые не зашифрованы сквозным способом — сообщения группового чата, обновления каналов или просто так называемые «облачные чаты» по умолчанию — шифруются MTProto 2 с использованием ключа, используемого для клиент-серверного взаимодействия (в документации он называется «ключ авторизации»).
Если сообщение зашифровано сквозным способом — то есть является частью секретного чата — оно сначала шифруется MTProto 2 с использованием ключа, согласованного между устройством получателя и устройством отправителя. Затем зашифрованное сквозным способом сообщение инкапсулируется в другое сообщение MTProto 2, на этот раз зашифрованное с использованием «ключа авторизации» (auth_key), используемого для клиент-серверного шифрования.
Этот «ключ авторизации», используемый для шифрования сообщений между клиентом и сервером, согласовывается один раз на каждом устройстве и, по-видимому, действителен для связи с любым сервером в «датацентрах» Telegram, которому клиентское устройство было назначено во время регистрации, в течение всего периода жизни клиента на этом устройстве.
В документации Telegram упоминается, что «в будущем» при определенных условиях клиентское устройство может быть прикреплено к другому дата-центру, таким образом вызывая согласование нового «ключа авторизации». Но в целом клиентскому устройству «дата-центр» Telegram назначается один раз, используя тот же долгосрочный «ключ авторизации» в качестве основы для всего клиент-серверного взаимодействия Telegram.
auth_key_id
Каждое зашифрованное сообщение MTProto 2 начинается с 64-битного значения в открытом виде (cleartext),auth_key_id. Это значение вычисляется из «ключа авторизации», который используется для шифрования клиент-сервер, и должно быть строго уникальным в пределах «дата-центра» Telegram.
Другими словами,auth_key_id, вычисленный из долгосрочного «ключа авторизации», однозначно идентифицирует конкретное клиентское устройство Telegram, используемое конкретным пользователем Telegram.
Я проверил, что когда я блокирую IP-адрес определенного сервера, к которому клиент Telegram на моем устройстве постоянно подключался, он будет подключаться к другому IP-адресу в той же подсети, но использовать тот же самый долгосрочныйauth_key_id(или текущий активный временныйauth_key_id, если используется perfect forward secrecy — я объясню это ниже).
Я также заметил, что независимо от того, из какой точки мира подключается клиент на моем устройстве, он всегда, похоже, подключается к одному и тому же IP-адресу сервера или, по крайней мере, к той же подсети, аauth_key_id, полученный из того же самого долгосрочного ключа (или, опять же, текущего активного временного «ключа авторизации»), виден в незашифрованной части сообщения.
Я проверил все это, наблюдая одни и те же незашифрованные, долгосрочные или временныеauth_key_idв разных перехваченных пакетах, независимо от того, откуда подключался клиент Telegram на моем устройстве или к какому IP-адресу сервера Telegram он подключался. Я изменил свой внешний IP с помощью Tor, а также протестировал это без Tor в двух географически удаленных местах (Исландия и Польша). Ниже я опишу свою тестовую настройку и углублюсь в анализ записанного трафика.
Если бы кто-то мог видеть весь трафик, входящий и исходящий из инфраструктуры Telegram, он бы мог отслеживать людей по всему миру, наблюдая за их передаваемыми открытым текстомauth_key_id, добавленным к зашифрованным MTProto сообщениям, таким образом узнавая IP-адреса, используемые их устройствами в любой момент времени.
Они также могли бы вычислить, кто и с кем именно общается, сопоставляя входящий и исходящий трафик из инфраструктуры Telegram на основе размера пакетов и временных меток, снова соотнося определенные пакеты с определенными пользовательскими устройствами основываясь на значенииauth_key_id.
Как этот кто-то мог бы связать определенныйauth_key_idс устройством определенного человека в первую очередь? Возможно, это так же просто, как спросить Telegram — сервис предоставил данные о десятках тысяч пользователей только в первом квартале 2025 года. Неясно, какие данные предоставляются, но разумно предположить, что IP-адреса (если не самиauth_key_id) и временные метки там есть. IP-адреса и временной метки было бы достаточно, чтобы связать человека, использующего сервис, с открытым текстомauth_key_idиз перехватов пакетов, если кто-то уже перехватил соответствующий трафик.
Да, люди, использующие Telegram, могут использовать Tor или VPN, чтобы скрыть свой настоящий IP-адрес. Я хочу сказать здесь не о том, что невозможно скрыться от такого рода слежки, облегчаемой дизайном протокола Telegram и выбором поставщиков инфраструктуры, а скорее о том, что эти, казалось бы, не связанные между собой решения Telegram, по-видимому, работают вместе исключительно хорошо, чтобы облегчить такой вид слежки в первую очередь.
Обфускация
Сначала я не мог найти то, что искал в своих перехваченных пакетах. Немного покопавшись, я понял, что иногда Telegram обфусцирует пакеты, используя довольно тривиальную схему. По какой-то причине все пакеты в моих собственных перехватах были обфусцированы таким образом.
В документации Telegram ясно указано, что это не схема шифрования, а такой механизм предназначен якобы только для того, чтобы помешать некоторой тривиальной фильтрации пакетов, развернутой для блокировки трафика Telegram. Я написал инструмент деобфускации для перехваченных пакетов Telegram, чтобы упростить мой анализ, который вы можете найти здесь, вместе с основными инструкциями по использованию.
Я решил опубликовать этот код, чтобы другие могли воспроизвести мои результаты относительноauth_key_idи дополнительно проанализировать протокол и его последствия.
Я считаю, что публикация не подвергает пользователей Telegram какой-либо дополнительной опасности: схема обфускации тривиальна, хорошо документирована в документации Telegram и уже реализована в бесчисленных библиотеках с открытым исходным кодом. Если кто-то подслушивает передаваемый трафик, у него уже есть своя собственная реализация, уже интегрированная, оптимизированная и развернутая.
Perfect Forward Secrecy и временные auth_key_id
MTProto 2 поддерживает perfect forward secrecy (PFS). При его использовании временный «ключ авторизации» согласовывается с использованием текущего используемого ключа авторизации, а затем идентификатор этого нового ключа (временныйauth_key_id) добавляется к сообщениям вместо долгосрочногоauth_key_idустройства.
Похоже, что эти временные ключи действительны только в течение 24 часов. Когда срок действия временного ключа авторизации истекает или вот-вот истечет, новый ключ согласовывается с использованием сообщений, зашифрованных старым ключом, и сauth_key_idстарого ключа, добавленным в виде открытого текста.
Как я покажу позже, это означает, что любой, кто может наблюдать за всем общением между клиентами Telegram и серверами Telegram, может легко отслеживать эти временныеauth_key_id, связанные с определенным пользовательским устройством, даже если используется PFS и все новые временные «ключи авторизации» согласовываются без использования долгосрочного постоянногоauth_key_idустройства.
Это связано с тем, что крайне маловероятно, что IP-адрес клиента и временныйauth_key_idизменятся одновременно. Если клиент повторно подключается с нового IP-адреса, он будет использовать уже наблюдаемыйauth_key_id. Когда создается новый временныйauth_key_id, он появляется в трафике сразу после использования старого. Некоторые из приведенных ниже перехватов происходили с разницей в несколько недель или из физически удаленных мест, но временныеauth_key_id, видимые в них, легко позволили бы идентифицировать клиентское устройство.
Переизобрели TLS, получилось не очень
Протокол TLS широко используется, хорошо понятен, постепенно совершенствуется в течение десятилетий, многократно проверяется и проверен в боевых условиях. Он обеспечивает именно то, что нужно для клиент-серверной связи в контексте такой системы, как Telegram, а именно конфиденциальность и целостность связи. TLS поддерживает perfect forward secrecy.
В нем доступна инфраструктура открытых ключей, а также certificate pinning и другие возможности, которые в совокупности означают, что идентификатор ключа клиентского устройства в виде открытого текста никогда не должен передаваться в открытом виде. Например, TLS используется мессенджером Signal в качестве шифрования транспортного уровня.
И все же, по непонятной причине, Telegram решил в основном использовать свой собственный MTProto 2 для клиент-серверного транспорта вместо использования проверенного TLS. Хотя технически HTTPS является одним из возможных транспортов MTProto 2, но я не нашел никаких указаний на использование HTTPS в качестве транспортного уровня ни в одном из проанализированных мной перехватов пакетов.
После того, как «ключ авторизации» Telegram согласован между клиентом и сервером, его необходимо каким-то образом идентифицировать в сообщении, чтобы принимающая сторона (например, серверы Telegram) знала, какой ключ использовать для его расшифровки. Таким образом, этот идентификатор,auth_key_id, необходимо добавлять к сообщениям в открытом виде.
Кроме того, MTProto 2 довольно очевиден в перехватов пакетов, отчасти из-за последовательностей байтов, которые идентифицируют, какой конкретный формат используется в каждом конкретном случае (протокол поддерживает большой выбор транспортов). Вероятно, поэтому пришлось добавить слой обфускации, чтобы можно было помешать относительно тривиальной фильтрации пакетов.
Ничего из этого не понадобилось бы, если бы Telegram решил использовать TLS для клиент-серверного транспорта.
TLS — не единственный доступный вариант, конечно. WhatsApp использует Noise Pipes, который также, по-видимому, избегает всех этих ловушек, предоставляя схожий функционал.
Глобальные возможности
Это не первый раз, когда люди обращают внимание наauth_key_idи возможность отслеживать конкретных людей благодаря нему. Об этом уже сообщалось ранее, например, вот здесь.
Кажется, всегда предполагалось, что это может быть проблемой, когда вы находитесь в стране, где государство может иметь полную видимость сети (например, через СОРМ), но если вы находитесь за пределами этих областей и подключаетесь к серверам Telegram, физически расположенным за пределами РФ (Telegram имеет инфраструктуру, размещенную в разных юрисдикциях), это гораздо менее важно.
Отчет iStories* показывает, что спецслужбы РФ через выбранного Telegram глобального поставщика инфраструктуры могли бы иметь доступ ко всему трафику, поступающему на серверы Telegram и с них, где бы они физически ни находились в мире и откуда бы ни исходил трафик.
В сочетании с передаваемым открытым текстом долгосрочнымauth_key_id(или его временной версии) в сети это дает майорам глобальную возможность отслеживать перемещения всех пользователей Telegram.
За эти годы Telegram стал чрезвычайно популярным, особенно в России и Восточной Европе; в 2024 году, как сообщается, у него было 950 миллионов активных аккаунтов по всему миру. Это означает возможность отслеживать физические перемещения огромного количества людей, включая диссидентов, солдат, активистов, политиков и так далее.
Это также означает, что каждый раз, когда кто-либо использует или продвигает Telegram, он невольно поддерживает эту возможную операцию по слежке, усиливая "сетевой эффект", вовлекая все больше людей в эту сеть и удерживая их там.
Наконец, что меня действительно поражает, так это то, что мы — сообщество специалистов в области информационной безопасности — годами сосредоточивались на том, надежна ли схема шифрования Telegram, в то время как очевидная (оглядываясь назад) проблема слежки на основе метаданных смотрела нам прямо в лицо, прямо в открытом тексте в дампах пакетов.
Тем более следует отдать должное журналистам-расследователям из IStories, которые задавали правильные вопросы и упорно искали ответы.
Погружаемся в технические подробности
Ниже я углублюсь в технические детали: используемую мной тестовую установку, немного о схеме обфускации протокола Telegram и, наконец, анализ конкретных перехватов пакетов.
Мой анализ был сосредоточен на Telegram для Android. Я сделал свои собственные перехваты пакетов, в том числе во время регистрации учетной записи Telegram, которую я использовал для этого. Эти перехваты выполнялись короткими сеансами, распределенными на протяжении нескольких недель, пока я был в Исландии и Польше.
Я также сделал анализ перехватов пакетов, сделанных другими для расследования IStories*, как Telegram Desktop, так и Telegram для Android, включая пакеты, захваченные в России. Они также подтвердили мои выводы, но я не имею права делиться необработанными данными.
Тестовая среда
Тестовая установка, которую я использовал, состояла из машины QubesOS, на которой у меня были:
• обычная сетевая установка QubesOS (sys-net,sys-firewall);
• сетевая виртуальная машина Tor (sys-whonix);
• виртуальная машина для анализа пакетов (telegram-sniff);
• виртуальная машина Ubuntu, работающая под управлением Waydroid с установленным Telegram для Android (telegram-apk).
Я использовал Telegram для Android версии v11.9.2 (5901). APK был скачан напрямую с веб-сайта Telegram.
Виртуальная машинаtelegram-apkиспользовала виртуальную машинуtelegram-sniffв качестве своего сетевого аплинка. Тот, в свою очередь, использовал в качестве сетевого аплинка либоsys-firewall(стандартная настройка QubesOS), либоsys-whonix(когда я хотел направить трафик через Tor). Я использовал Wireshark, запущенный в виртуальной машинеtelegram-sniff, для выполнения дампов пакетов. Когда мне нужно было заблокировать определенные IP-адреса серверов Telegram, я делал это в виртуальной машинеtelegram-sniff.
Это означало, что я мог изменить базовую сетевую настройку и выполнить перехват пакетов, при этом убедившись, что приложение Telegram не сможет заметить или помешать им.
Перехваты пакетов
Все обсуждаемые ниже перехваты пакетов доступны здесь. Они содержат только трафик, связанный с Telegram. Имена файлов содержат таймстамп первого пакета и описание того, что происходило во время перехвата пакетов.
Большинство наблюдавшихся мной пакетов оказались обфусцированы с использованием схемы обфускации MTProto 2. Как уже упоминалось, я написал инструмент для их деобфускации и попытки извлечьauth_key_id. Ниже приведен вывод этого инструмента.
Инструмент работает с данными, извлеченными из дампов пакетов. Единственные пакеты, которые содержатauth_key_id, — это начальные пакеты данных TCP-потоков. Итак, чтобы подготовить файлы*.payloadsдля обработки инструментом, нам нужны:
1. идентификация всех полных потоков TCP в файле перехвата пакетов;
2. извлечение данных payload'а только из первого пакета каждого потока.
Репозиторий инструмента деобфускации содержит короткий скрипт на основеtshark, который делает именно это.
Всякий раз, когдаauth_key_idпечатается инструментом деобфускации, это означает, что:
1. данные в пакете были фактически обфусцированы;
2. после деобфускации данные содержали маркерef:ef:ef:efсокращенный транспорт в ожидаемом смещении.
"Нулевой"auth_key_idиз00:00:00:00:00:00:00:00указывает на сообщение, которое не зашифровано или, иным образом, является служебным сообщением. В частности, сообщения, которые используются в процессе согласования ключа авторизации, будут иметьauth_key_id, целиком состоящий из нулей.
Каждый отдельный файл перехвата пакетов был сохранен во время одного сеанса, что означает один внешний IP-адрес. Я не показываю здесь IP-адреса, потому что перехваты были сделаны во внутренней сети QubesOS и включают только адреса IPv4 частной сети. Внешние IP-адреса менялись между каждым сеансом.
Обфускация (маскировка)
При просмотре payload'ов пакетов, несущих MTProto 2, следует увидеть контрольные маркеры одной из многих транспортных схем MTProto 2, а затемauth_key_idнесколькими байтами позже (в зависимости от используемой схемы). Но я продолжал получать рандомные данные, например:
fa:8f:85:46:94:ab:c7:21 3d:9a:31:61:43:f3:34:e6 ed:43:41:fc:9b:c4:65:20 83:27:f5:ff:0c:20:47:e7
de:f1:24:09:39:6d:9a:1f 31:4e:47:b0:1c:be:93:b3 aa:ed:1a:f2:4b:0a:cc:d2 9c:6c:32:90:1c:25:f9:73
29:e1:09:02:e1:3a:da:77 e5:76:53:4b:4c:c6:e4:b9 6d:c7:af:50:16:d4:30:49 8f:4e:c6:50:56:ac:cc:a3
(...)
Это означало, что данные были зашифрованы. При прохождении через мою библиотеку деобфускации их содержимое выглядит так:
95:f8:27:6a:d4:e2:2c:82 77:eb:6d:8d:fd:78:4e:2e 78:a0:b5:54:e7:f9:8a:9c 65:3c:04:c1:d5:68:b4:34
79:1c:3d:4e:ec:ae:23:b9 aa:db:73:ce:16:86:09:33 8e:9a:e7:73:6d:1c:ab:1e ef:ef:ef:ef:ed:b2:26:37
2a:64:0a:8a:ff:3a:83:75 54:57:07:07:e2:06:3d:a5 f7:8d:60:f6:a0:48:f3:61 49:f9:2a:3d:1f:ce:1a:df
(...)
Где:
• ef:ef:ef:ef- маркер "сокращенного" транспорта MTProto 2 при использовании с обфускацией;
• ed:b2:26:37- просто случайные данные, оставшиеся после обфускации (в некоторых случаях их можно использовать для информации, связанной с "датацентрами" Telegram, но здесь это, похоже, не имеет значения);
• 2a- длина фактического payload'а сообщения MTProto 2;
• 64:0a:8a:ff:3a:83:75:54-auth_key_idв самом начале сообщения MTProto 2.
Данные перед маркеромef:ef:ef:efпредставляют собой случайный шум, результат «деобфускации» ключа и вектора инициализации для AES-CTR, используемых для обфускации. Ключ — это байты с 8 по 39 исходного содержимого пакеты (да, передаваемые открытым текстом — в противном случае было бы невозможно деобфусцировать его на другом конце), а также байты вектора инициализации с 40 по 55.
Байты с 0 по 7, похоже, важны для сервера только в той мере, в какой ему нужно выяснить, какой транспорт и формат используются — по сути, они не должны содержать определенных магических последовательностей байтов, чтобы их можно было рассматривать как обфусцированный MTProto 2.
Регистрация и первое сообщение
Мы получаем несколько потенциальныхauth_key_idиз прослушивания во время первоначальной регистрации:
Единственное, что повторяется здесь несколько раз -- помимо00:00:00:00:00:00:00:00nullauth_key_id-- это64:0a:8a:ff:3a:83:75:54, так что это, вероятно, долгосрочныйauth_key_id. Но мы должны записать их все.
Фоновые сеансы
Три разных фоновых сеанса (то есть без фактического запуска приложения Telegram явным образом). Виртуальная машинаtelegram-apkбыла перезапущена между этими сеансами.
Наш предполагаемый долгосрочныйauth_key_id, очевидно, виден:
Фоновые сеансы через Tor
Когда Tor используется для изменения внешнего IP-адреса, с которого будут устанавливаться соединения с серверами Telegram, снова очевидно виден предполагаемый долгосрочныйauth_key_id
Это также верно для случая, когда я заблокировал IP-адрес, к которому приложение Telegram продолжало подключаться, а затем снова разблокировал его:
Присоединение к каналу
Когда я присоединился к каналу, физически находясь в Польше, а не в Исландии, изначально был виден долгосрочныйauth_key_id
Похоже, что в этот момент включилась perfect forward secrecy и было согласовано несколько временных ключей авторизации (на что, вероятно, указывают нулевыеauth_key_id, за которыми следовали новые значения). Любой, кто прослушивал мой трафик на линии, мог это заметить, а также заметить, что все эти новыеauth_key_idпоявляются в пакетах с того же IP-адреса, что и те, что наблюдались ранее.
Некоторые из предположительно временных ключей (идентификаторы:c7:33:a1:24:02:4f:3c:36,58:d6:c4:e6:fa:bb:0b:68,eb:40:17:49:1e:e4:93:c9) появляются в более раннем перехвате. Другие (идентификаторы:20:0d:a0:1e:f7:32:e3:2b,27:41:c4:eb:5e:b6:b5:63) оказались использованы позже.
Разговор с ботом
Следующий сеанс не включал предполагаемый долгосрочныйauth_key_id. Это соответствует документации Telegram, которая требует, чтобы долгосрочныйauth_key_idне использовался после использования временных ключей для обеспечения совершенной прямой секретности:
Но он содержал два идентификатора (20:0d:a0:1e:f7:32:e3:2b,27:41:c4:eb:5e:b6:b5:63) предположительно временныхauth_key_id, которые ранее были замечены в том же перехвате пакета, что и долгосрочный.
Это было верно и тогда, когда я переключился на Tor, чтобы соединение, казалось, происходило из совершенно другого места:
Другими словами, эти перехваты пакетов, даже если они не содержат долгосрочныйauth_key_id, все равно могут быть легко привязаны к одному и тому же пользователю: временныеauth_key_id, которые видны здесь, наблюдались вместе с долгосрочным ранее (связаны с ним через IP-адрес). Любые новые временныеauth_key_idбыли бы согласованы с использованием текущих временныхauth_key_idи, таким образом, могли бы быть связаны с тем же устройством тем же способом.
Пока у нас есть необходимая глобальная сетевая видимость. Которая, благодаря выбору Telegram поставщиков инфраструктуры, похоже, есть у российских спецслужб.
Подключение после долгого перерыва
Я сделал перерыв на пару недель, чтобы посмотреть, что произойдет с временнымиauth_key_id.
После повторного подключения я снова мог наблюдать старые временныеauth_key_id(20:0d:a0:1e:f7:32:e3:2b,e5:c2:9a:fd:8d:5a:23:16,09:02:40:0f:1a:62:85:89,e7:ee:21:9f:3b:a4:4a:1d,27:41:c4:eb:5e:b6:b5:63,31:b1:e9:42:76:5f:1e:66), за которыми следовали недавно сгенерированные (ba:96:5e:72:66:b8:17:91,3c:47:69:e8:ba:09:a3:ff,02:5a:6b:98:cc:a4:ea:ce):
Выводы
На основании анализа вышеприведенных данных о перехваченных пакетах, я считаю очевидным, что любой, кто имеет достаточный доступ к трафику клиентов Telegram, может идентифицировать и отслеживать трафик конкретных устройств пользователей, использующих этот сервис. В том числе и в случае использования протокола Perfect Forward Secrecy.
Это также позволит, посредством дополнительного анализа на основе времени и размера пакетов, потенциально идентифицировать, кто с кем общается с помощью Telegram.
(источник)
