Куда и как ходит Telegram?

Начнём с простого. Telegram-клиенты общаются с Telegram-серверами по собственному протоколу MTProto поверх TCP. Для соединения используются несколько адресов, которые не изменялись годами и продолжают являться основными точками подключения. Возьмём для примера один из адресов европейского региона: 149.154.167.40.

Обычно используется порт 443, но никакого отношения к SSL/TLS это не имеет.

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

Обратите внимание, что даже в зашифрованных пакетах есть постоянные заголовки: первые 8 байт будут одинаковыми в пределах сессии, так как представляют из себя отпечаток авторизационного ключа. К этому моменту мы скоро вернёмся.

Роскомнадзор, мать его

И тут в игру вступает злое государство и его орган, регулирующий интернет, который начинает блокировку Telegram! В нашем случае это Роскомнадзор, который добавляет в выгрузку для провайдеров все подсети Telegram, в том числе ту, в которой находится наш 149.154.167.40. Провайдеры получают выгрузку и закрывают доступ пользователям к указанным адресам.

Команда Telegram, конечно, не оставила нас в беде. Ребята запустили множество серверов у разных хостинг-провайдеров, которые стали принимать пакеты и переадресовывать их на основные Telegram-сервера, попавшие под блокировку.

Откуда же приложение на вашем телефоне/компьютере узнает адреса этих новых серверов? Используются два метода.

Как доставить новые адреса серверов клиентам?

DC_UPDATE

Это первый способ, которым адреса новых серверов доставляются на устройства пользователей. Подходит он только для мобильных клиентов на iOS и Android, потому что использует Apple Push Notification Service и Google Cloud Messaging соответственно. Команда Telegram отправляет вам на устройства push-уведомления, внутри которых содержится список новых адресов. Приложение Telegram считывает их и начинает использовать эти адреса для связи.

Плюсы DC_UPDATE:

1. Помешать затее можно только заблокировав APNS и GCM полностью, что лишит вас всех уведомлений от всех приложений, даже если вы никогда не пользовались Telegram. На это власти не пойдут (?).
2. В теории этот способ позволяет отправлять разным группам пользователей разные адреса, что может отсрочить блокировку новых серверов и помочь команде Telegram вычислить шпионов. На практике эта хитрость, насколько я знаю, не используется.

Минусы DC_UPDATE:

1. Подходит только для мобильных устройств, так как на десктопных операционных системах нет единого механизма доставки уведомлений.
2. Может работать нестабильно. Если уведомление по каким-то причинам до вас не дошло, приложение Telegram не узнает о новых адресах. Особенно актуально для iOS, где приложения сильно ограничены в фоновой обработке уведомлений. Именно поэтому на iOS такие push видны пользователю и требуют нажатия для активации.

Роскомнадзор выслеживает новые адреса, приходящие в DC_UPDATE и блокирует их.

Domain fronting

Этот способ доставки адресов не так широко известен, а многие вовсе не понимают, как он работает.

Для начала рекомендую прочитать общее описание. Telegram же просто помещает зашифрованный список в TXT-записи своих сервисных доменов и на платформе Azure. Затем клиенты запрашивают эти данные с адресов dns.google.com и tcdnb.azureedge.net/prodv2/config.txt. Техника domain fronting позволяет сделать так, что провайдерские системы фильтрации и блокировок видят это как запросы к google.com и software-download.microsoft.com.

Плюсы domain fronting:

1. Для блокировки этого способа придётся заблокировать весь google.com и сервис доставки обновлений Windows. Роскомнадзор на такое пойти не может. Однажды они блокировали google.com, но дали заднюю.
2. Может работать и работает на любых платформах, включая десктопные.

obfuscated2: Защита от более продвинутого DPI

Что, если регулирующий интернет орган вроде Роскомнадзора станет чуть умнее? Если ещё не забыли, в начале статьи я упомянула, что даже в зашифрованных пакетах Telegram всегда есть постоянные заголовки. При желании провайдер может отслеживать эти заголовки и блокировать соединения на основании содержимого пакета, а не адресов серверов. Тогда все вышеописанные техники защиты станут бесполезными, подумаете вы, и окажетесь правы. Почти правы.

Telegram ещё как минимум в начале 2017 года реализовал защиту от подобных «лишних глаз», заглядывающих в пакеты.

Несмотря на то, что протокол MTProto открыт и описан на официальном сайте Telegram, официальные же клиенты используют дополнительный слой обфускации, нигде не документированный. Товарищ Tomas Susanka уже максимально подробно описал используемый метод обфускации пакетов, поэтому расписывать всё не буду.

Клиент придумывает случайный 32-байтовый ключ и случайный 16-байтовый Initialization Vector, которыми шифрует каждый пакет с помощью AES CTR, а чтобы сервер узнал, как это расшифровать... ключ и IV добавляются в начало пакета перед зашифрованным содержимым.

Вы назовёте это глупостью, ведь какой смысл отправлять зашифрованные пакеты и сразу прикладывать к ним ключ для расшифровки? Конечно, это абсолютно бесполезная защита в логическом смысле, но она имеет большой смысл на практике.

После обфускации все пакеты выглядят как случайный мусор, поэтому для определения, Telegram-трафик это или нет, провайдеру придётся расшифровывать каждый непонятный пакет по методике obfuscated2, прежде чем проводить дальнейшие проверки. Такие действия требуют неоправданное количество вычислительных мощностей, которых у провайдеров попросту нет.

Подключение к Telegram через прокси

Как уже было сказано выше, команда Telegram прикладывает много усилий, чтобы обойти государственные блокировки, но это не всегда работает. Временные сервера быстро блокируются Роскомнадзором и мы снова теряем доступ к мессенджеру.

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

SOCKS5-прокси

Очень банальный, но действенный способ. Если сможете осилить технический английский, почитайте вот этот RFC-документ.

Клиент Telegram подключается к заданному вами SOCKS5-серверу и уже через него устанавливает соединение с Telegram-серверами. Так как SOCKS5-сервер находится вне страны, которая ввела блокировки, соединения между ним и Telegram устанавливаются успешно.

Простая лазейка будет работать до тех пор, пока сам прокси-сервер не будет отслежен и заблокирован.

Плюсы SOCKS5-прокси:

1. Очень быстро и очень просто.
2. Всем известный протокол, серверные реализации которого существуют под все платформы и ОС.

Минусы SOCKS5-прокси:

1. Протокол очень легко детектируется с помощью DPI, государство может легко в принципе запретить использование SOCKS5 и заблокировать его.
2. Логин и пароль для авторизации передаются в открытом виде. Никогда не используйте для авторизации в SOCKS5 пароли, которые используете где-либо ещё.
3. Если ваше Telegram-приложение получало с помощью ранее описанных методов IP-адреса временных серверов, то при включении SOCKS5-прокси, приложение будет пытаться подключаться именно туда. Так как владельцы прокси, специализирующихся на Telegram, обычно блокируют соединения со всеми адресами, кроме основных подсетей Telegram, у пользователя могут иногда возникнуть проблемы с подключением.

MTPROTO-прокси

Наконец-то мы подошли к тому, чего вы так долго ждали.

Начнём с того, что любой MTPROTO-прокси — самый что ни на есть реверс-прокси. Это значит, что в отличие от SOCKS5, клиент не просит прокси достучаться до какого-то Telegram-сервера. Клиент общается с MTPROTO-прокси так, будто это уже Telegram-сервер.

Официальной документации по MTPROTO-прокси нет до сих пор, хотя в клиентах функциональность реализована давно. Некоторые умельцы написали свои реализации серверов, изучив исходный код клиентов. Вот, например, одна из них (C#).

MTPROTO-прокси-сервер просто принимает пакеты от клиента и отправляет Telegram-серверу. Обманула, не так просто. Давайте разберёмся.

Во-первых, клиент общается с MTPROTO-прокси только с обфускацией obfuscated2.

Во-вторых, obfuscated2 здесь используется чуть модифицированный. Перед зашифрованной частью всё так же открыто передаются ключ и IV, только вот шифруется сам пакет не этим ключом, а sha256(key+secret). Secret — это тот самый 16-байтовый параметр, который вы заполняете при подключении к MTPROTO-прокси.

Secret нигде не передаётся в процессе связи. Его использует клиент для шифрования пакета и MTPROTO-прокси-сервер для расшифрования.

MTPROTO-прокси-сервер получает от вас пакет, деобфусцирует его ключом sha256(key+secret), затем снова обфусцирует, но уже используя обычный obfuscated2 без дополнительных параметров.

Таким образом получается, что сторонний человек никак не может деобфусцировать и классифицировать трафик между клиентом и MTPROTO-прокси-сервером.

Плюсы MTPROTO-прокси:

1. Трафик между клиентом и промежуточным звеном выглядит как случайный мусор, который при всём желании и наличии вычислительных мощностей не может быть деобфусцирован провайдерами.
2. Это реверс-прокси, поэтому клиентам не нужно реализовывать никаких новых протоколов. Только obfuscated2 и поле для ввода secret. Клиент присоединяется к MTPROTO-прокси как к обычному Telegram-серверу.

Минусы MTPROTO-прокси:

1. Каждый пакет должен быть дешифрован и зашифрован снова на стороне прокси-сервера. В Vee Security мы используем самописную реализацию SOCKS5-сервера, которая позволяет нам держать миллионы одновременных подключений. Ещё не проводила оценку, но уверена, что в самой идеальной реализации MTPROTO-прокси-сервера результаты будут в разы хуже. Этот минус убивает очень многое. Не ждите такого большого количества стабильных публичных прокси-серверов, как в случае с SOCKS5.
2. От команды Telegram до сих пор нет никакой официальной документации, примеров реализации и прочих объяснений происходящему. Возможно, ещё не пришло время. Ждём.
3. Невозможность проксировать голосовой трафик в звонках. Голосовой трафик при отключенном P2P передаётся через relay-сервера, которые не работают по протоколу MTProto, поэтому узкоспециализированный MTPROTO-прокси не подходит для передачи таких данных.

Кстати, в идею MTPROTO-прокси заложена возможность насильного отображения у пользователей вашего сервера так называемого «канала-спонсора». Это поможет держателям серверов с MTPROTO-прокси монетизировать свои начинания. Лично я к таким штукам отношусь негативно, но кушать всем надо.