Включили VPN и успокоились? Криптографы доказали, что Telegram все равно выдает ваше устройство
NewsMakerЭксперты нашли способ следить за пользователями Telegram через скрытую метку.
Спор вокруг приватности Telegram вышел за пределы обычного вопроса о шифровании переписки. Новый 89-страничный отчет Symbolic Software утверждает, что протокол MTProto раскрывает пассивным сетевым наблюдателям 64-битный auth_key_id, а по этому параметру устройство потенциально можно узнавать после перезапуска приложения, смены IP-адреса, подключения через VPN и перехода между сетями.
Документ подготовил криптограф Надим Кобейсси из Symbolic Software по заказу Global Network Solutions, Inc. Материалы IStories и OCCRP быстро привлекли к выводам внимание за пределами профессиональной дискуссии: журналисты связали обзор с прошлым расследованием о сетевой инфраструктуре мессенджера.
Авторы сосредоточились на auth_key_id, идентификаторе ключа авторизации в заголовке каждого сообщения MTProto. Клиент использует параметр, чтобы сервер мог выбрать нужный ключ для обработки зашифрованного сообщения. Содержимое переписки по одному auth_key_id прочитать нельзя, но отчет говорит о другом риске: стабильная метка в сетевом трафике способна связать активность одного устройства в разных сетях и местах.
По версии исследователей, клиенты Telegram для Android и настольных систем передают MTProto по обычным TCP-соединениям, а не через HTTPS или TLS. Порт 443 может создавать видимость защищенного веб-трафика, но в перехваченных пакетах авторы не нашли TLS-рукопожатия, обмена сертификатами и транспортного шифрования. После снятия простой обфускации auth_key_id остается видимым в заголовке MTProto.
Пассивному наблюдателю, по оценке авторов, не нужно взламывать шифрование, подменять сертификаты или вмешиваться в соединение. Провайдер, администратор корпоративной сети, оператор Wi-Fi в гостинице, мобильный оператор или иной участник маршрута могут фиксировать auth_key_id вместе с IP-адресом, временем подключения и характером трафика. После первоначальной привязки идентификатора к известному человеку журнал наблюдений способен показать, где и когда появлялось конкретное устройство.
Отдельный вывод касается Secret Chats и Perfect Forward Secrecy. Сквозное шифрование защищает содержимое секретных чатов, а PFS снижает риск расшифровки старых сообщений при компрометации ключей. Но авторы отчета считают, что обе меры не закрывают наблюдение по auth_key_id, поскольку утечка, по версии исследователей, происходит ниже уровня содержимого: в заголовке MTProto, который передается вместе с любым типом чата.
Исследователи также утверждают, что auth_key_id в тестах не менялся при перезапуске приложения, смене IP-адреса, переходе между Wi-Fi и VPN, подключении к другим серверам внутри дата-центра и наблюдении в течение нескольких дней или недель. Авторы отдельно оговаривают важное ограничение: auth_key_id сам по себе отслеживает устройство, а не сразу устанавливает личность пользователя. Для связи с конкретным человеком нужен отдельный момент сопоставления, например вход через сеть, где личность уже известна.
Symbolic Software предлагает обязать все соединения MTProto использовать шифрование транспортного уровня, например TLS. Авторы считают, что пользовательские настройки не убирают риск, поскольку проблема связана с архитектурой транспорта, а не с выбором режима чата.
Telegram с выводами не согласился. В ответе компания заявила, что auth_key_id регулярно меняется, не содержит данных пользователя, не раскрывает содержимое сообщений, получателей и личную информацию. Telegram также утверждает, что наблюдатель, способный видеть auth_key_id, уже получает более надежные сетевые сигналы для отслеживания: IP-адрес, имена подключенных серверов, DNS-запросы и характер трафика.
Компания отдельно отвергла утверждения о доступе сторонних подрядчиков к пользовательским данным и инфраструктуре. Telegram заявляет, что владеет серверами, управляет сетью через внутренние инженерные команды и использует модель нулевого доверия, при которой физический доступ к оборудованию не дает доступа к пользовательским данным, прикладному трафику, ключам шифрования и внутренним системам.
Главный спор упирается не в возможность читать переписку, а в видимость сетевых метаданных. Symbolic Software считает auth_key_id устойчивой меткой для долгосрочного наблюдения за устройством при доступе к сетевому маршруту. Telegram настаивает, что параметр регулярно меняется, не раскрывает приватные данные и не добавляет стороннему оператору возможностей, которых у владельца сетевой инфраструктуры еще нет.
Спор вокруг приватности Telegram вышел за пределы обычного вопроса о шифровании переписки. Новый 89-страничный отчет Symbolic Software утверждает, что протокол MTProto раскрывает пассивным сетевым наблюдателям 64-битный auth_key_id, а по этому параметру устройство потенциально можно узнавать после перезапуска приложения, смены IP-адреса, подключения через VPN и перехода между сетями.
Документ подготовил криптограф Надим Кобейсси из Symbolic Software по заказу Global Network Solutions, Inc. Материалы IStories и OCCRP быстро привлекли к выводам внимание за пределами профессиональной дискуссии: журналисты связали обзор с прошлым расследованием о сетевой инфраструктуре мессенджера.
Авторы сосредоточились на auth_key_id, идентификаторе ключа авторизации в заголовке каждого сообщения MTProto. Клиент использует параметр, чтобы сервер мог выбрать нужный ключ для обработки зашифрованного сообщения. Содержимое переписки по одному auth_key_id прочитать нельзя, но отчет говорит о другом риске: стабильная метка в сетевом трафике способна связать активность одного устройства в разных сетях и местах.
По версии исследователей, клиенты Telegram для Android и настольных систем передают MTProto по обычным TCP-соединениям, а не через HTTPS или TLS. Порт 443 может создавать видимость защищенного веб-трафика, но в перехваченных пакетах авторы не нашли TLS-рукопожатия, обмена сертификатами и транспортного шифрования. После снятия простой обфускации auth_key_id остается видимым в заголовке MTProto.
Пассивному наблюдателю, по оценке авторов, не нужно взламывать шифрование, подменять сертификаты или вмешиваться в соединение. Провайдер, администратор корпоративной сети, оператор Wi-Fi в гостинице, мобильный оператор или иной участник маршрута могут фиксировать auth_key_id вместе с IP-адресом, временем подключения и характером трафика. После первоначальной привязки идентификатора к известному человеку журнал наблюдений способен показать, где и когда появлялось конкретное устройство.
Отдельный вывод касается Secret Chats и Perfect Forward Secrecy. Сквозное шифрование защищает содержимое секретных чатов, а PFS снижает риск расшифровки старых сообщений при компрометации ключей. Но авторы отчета считают, что обе меры не закрывают наблюдение по auth_key_id, поскольку утечка, по версии исследователей, происходит ниже уровня содержимого: в заголовке MTProto, который передается вместе с любым типом чата.
Исследователи также утверждают, что auth_key_id в тестах не менялся при перезапуске приложения, смене IP-адреса, переходе между Wi-Fi и VPN, подключении к другим серверам внутри дата-центра и наблюдении в течение нескольких дней или недель. Авторы отдельно оговаривают важное ограничение: auth_key_id сам по себе отслеживает устройство, а не сразу устанавливает личность пользователя. Для связи с конкретным человеком нужен отдельный момент сопоставления, например вход через сеть, где личность уже известна.
Symbolic Software предлагает обязать все соединения MTProto использовать шифрование транспортного уровня, например TLS. Авторы считают, что пользовательские настройки не убирают риск, поскольку проблема связана с архитектурой транспорта, а не с выбором режима чата.
Telegram с выводами не согласился. В ответе компания заявила, что auth_key_id регулярно меняется, не содержит данных пользователя, не раскрывает содержимое сообщений, получателей и личную информацию. Telegram также утверждает, что наблюдатель, способный видеть auth_key_id, уже получает более надежные сетевые сигналы для отслеживания: IP-адрес, имена подключенных серверов, DNS-запросы и характер трафика.
Компания отдельно отвергла утверждения о доступе сторонних подрядчиков к пользовательским данным и инфраструктуре. Telegram заявляет, что владеет серверами, управляет сетью через внутренние инженерные команды и использует модель нулевого доверия, при которой физический доступ к оборудованию не дает доступа к пользовательским данным, прикладному трафику, ключам шифрования и внутренним системам.
Главный спор упирается не в возможность читать переписку, а в видимость сетевых метаданных. Symbolic Software считает auth_key_id устойчивой меткой для долгосрочного наблюдения за устройством при доступе к сетевому маршруту. Telegram настаивает, что параметр регулярно меняется, не раскрывает приватные данные и не добавляет стороннему оператору возможностей, которых у владельца сетевой инфраструктуры еще нет.