Многие люди, занимающиеся информационной безопасностью, включая меня, давно считают 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 разработан таким образом, что он в основном препятствует использованию секретных чатов. Сквозное шифрование также вообще недоступно для групп и каналов. Я немного углубился в это здесь.

В 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, в то время как очевидная (оглядываясь назад) проблема слежки на основе метаданных смотрела нам прямо в лицо, прямо в открытом тексте в дампах пакетов.

---

Погружаемся в технические подробности

Ниже я углублюсь в технические детали: используемую мной тестовую установку, немного о схеме обфускации протокола Telegram и, наконец, анализ конкретных перехватов пакетов.

Мой анализ был сосредоточен на Telegram для Android. Я сделал свои собственные перехваты пакетов, в том числе во время регистрации учетной записи Telegram, которую я использовал для этого. Эти перехваты выполнялись короткими сеансами, распределенными на протяжении нескольких недель, пока я был в Исландии и Польше.

Тестовая среда

Тестовая установка, которую я использовал, состояла из машины 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 из прослушивания во время первоначальной регистрации:

файл обработки: 1746314533-telegram-mobile-first-registration-and-message.pcapng.payloads 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 8a:31:86:7d:2e:8e:0c:77 
   auth_key_id : 00:00:00:00:00:00:00:00
   auth_key_id : c6:00:00:4d:db:fa:12:b8 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : a6:00:00:ae:cf:27:cf:ba 
   auth_key_id : ae:cf:27:cf:ba:e1:58:d5 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : c7:33:a1:24:02:4f:3c:36 
   auth_key_id : 58:d6:c4:e6:fa:bb:0b:68 
   auth_key_id : eb:40:17:49:1e:e4:93:c9 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 

Единственное, что повторяется здесь несколько раз -- помимо 00:00:00:00:00:00:00:00 null auth_key_id -- это 64:0a:8a:ff:3a:83:75:54, так что это, вероятно, долгосрочный auth_key_id. Но мы должны записать их все.

Фоновые сеансы

Три разных фоновых сеанса (то есть без фактического запуска приложения Telegram явным образом). Виртуальная машина telegram-apk была перезапущена между этими сеансами.

Наш предполагаемый долгосрочный auth_key_id, очевидно, виден:

файл обработки: 1746315509-telegram-mobile-background-session-no-open-app.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
файл обработки: 1746318794-telegram-mobile-background-session-no-open-app2.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54  
файл обработки: 1746319193-telegram-mobile-фоновый-сеанс-no-open-app3.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id: 64:0a:8a:ff:3a:83:75:54 

Фоновые сеансы через Tor

Когда Tor используется для изменения внешнего IP-адреса, с которого будут устанавливаться соединения с серверами Telegram, снова очевидно виден предполагаемый долгосрочный auth_key_id:

файл обработки: 1746319792-telegram-mobile-background-session-no-open-app-via-tor1.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
файл обработки: 1746320078-telegram-mobile-background-session-no-open-app-via-tor2.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 

Это также верно для случая, когда я заблокировал IP-адрес, к которому приложение Telegram продолжало подключаться, а затем снова разблокировал его:

файл обработки: 1746326453-telegram-mobile-background-session-no-open-app-via-tor-91-blocked1.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
файл обработки: 1746327628-telegram-mobile-background-session-no-open-app-via-tor-after-91-unblocked1.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 

Присоединение к каналу

Когда я присоединился к каналу, физически находясь в Польше, а не в Исландии, изначально был виден долгосрочный auth_key_id:

файл обработки: 1747770014-telegram-mobile-open-app-join-minionquote-channel.pcapng.payloads 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : c7:33:a1:24:02:4f:3c:36 
   auth_key_id : 58:d6:c4:e6:fa:bb:0b:68 
   auth_key_id : eb:40:17:49:1e:e4:93:c9 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 4d:db:fa:12:b8:0b:2a:c8 
   auth_key_id : 00:00:00:00:00:00:00:00
   auth_key_id : ae:cf:27:cf:ba:e1:58:d5 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 3c:47:69:e8:ba:09:a3:ff 
   auth_key_id : f0:f6:f1:07:b1:a7:31:51 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 00:00:00:00:00:00:00:00
   auth_key_id : 3c:47:69:e8:ba:09:a3:ff 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66  
   auth_key_id : 31:b1:d9:42:76:5f:1d:66

Похоже, что в этот момент включилась 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 не использовался после использования временных ключей для обеспечения совершенной прямой секретности:

файл обработки: 1747770709-telegram-mobile-transparency-for-iceland.pcapng.payloads 
   auth_key_id: 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id: 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id: 27:41:c4:eb:5e:b6:b5:63 
файл обработки: 1747773654-telegram-mobile-transparency-for-iceland2.pcapng.payloads 
   auth_key_id: 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id: 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id: e5:c2:9a:fd:8d:5a:23:16 
   auth_key_id: 09:02:40:0f:1a:62:85:89 
   auth_key_id: e7:ee:21:9f:3b:a4:4a:1d 
   auth_key_id: 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id: 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id: 27:41:c4:eb:5e:b6:b5:63 

Но он содержал два идентификатора (20:0d:a0:1e:f7:32:e3:2b, 27:41:c4:eb:5e:b6:b5:63) предположительно временных auth_key_id, которые ранее были замечены в том же перехвате пакета, что и долгосрочный.

Это было верно и тогда, когда я переключился на Tor, чтобы соединение, казалось, происходило из совершенно другого места:

файл обработки: 1747787981-telegram-mobile-transparency-for-iceland3-over-tor.pcapng.payloads 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : e5:c2:9a:fd:8d:5a:23:16 
   auth_key_id : 09:02:40:0f:1a:62:85:89 
   auth_key_id : e7:ee:21:9f:3b:a4:4a:1d 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 

Другими словами, эти перехваты пакетов, даже если они не содержат долгосрочный 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):

файл обработки: 1749161835-telegram-mobile-transparency-for-iceland4-from-poland.pcapng.payloads 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : e5:c2:9a:fd:8d:5a:23:16 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00
   auth_key_id : 00:00:00:00:00:00:00:00
   auth_key_id : 09:02:40:0f:1a:62:85:89 
   auth_key_id : e7:ee:21:9f:3b:a4:4a:1d 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : ba:96:5e:72:66:b8:17:91 
   auth_key_id : ba:96:5e:72:66:b8:17:91 
   auth_key_id : ba:96:5e:72:66:b8:17:91 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 3c:47:69:e8:ba:09:a3:ff 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 02:5a:6b:98:cc:a4:ea:ce 
   auth_key_id : 02:5a:6b:98:cc:a4:ea:ce 

Выводы

На основании анализа вышеприведенных данных о перехваченных пакетах, я считаю очевидным, что любой, кто имеет достаточный доступ к трафику клиентов Telegram, может идентифицировать и отслеживать трафик конкретных устройств пользователей, использующих этот сервис. В том числе и в случае использования протокола Perfect Forward Secrecy.

Это также позволит, посредством дополнительного анализа на основе времени и размера пакетов, потенциально идентифицировать, кто с кем общается с помощью Telegram.

IStories ("Важные истории") признаны иноагентом и нежелательной организацией на территории РФ, поэтому ссылки на них удалены по просьбе администрации Хабра, но могут быть легко найдены в Гугле.