Содержание

Мобильный протокол MTProto

Пожалуйста, прочтите наш технический FAQ
Разработчикам клиентов нужно соблюдать наши требования безопасности

Связанные статьи

Общее описание

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

Протокол подразделён на три фактически независимых компонента:

  • компонент высокого уровня (язык запроса API): определяет метод, посредством которого запросы и ответы API конвертируются в двоичные сообщения.
  • криптографический слой (слой авторизации): определяет метод, которым шифруются сообщения перед тем как они будут переданы посредством протокола доставки.
  • компонент доставки: определяет для клиента и сервера метод передачи сообщений через некий другой существующий сетевой протокол (такой как http, https, tcp, udp).
MTProto encryption Примечание 1: Каждое текстовое сообщение, которое нужно зашифровать через MTProto, всегда содержит следующие данные, которые проверяются расшифровкой, чтобы сделать систему устойчивой против известных проблем с компонентами:
  • server salt (соль сервера) (64-битная)
  • session id (идентификатор сессии)
  • message sequence number (порядковый номер сообщения)
  • message length (длина сообщения)
  • time (время)

Краткий обзор компонентов

Компонент высокого уровня (язык запроса RPC/API)

С точки зрения компонента высокого уровня, клиент и сервер обмениваются сообщениями внутри сессии. Сессия привязана к девайсу клиента (к приложению, если точнее), а не к конкретному http/https/tcp соединению. Дополнительно, каждая сессия прикреплена к айди пользовательского ключа, которым собственно и завершается авторизация.

Может быть открыто несколько соединений с сервером; сообщения могут быть отправлены в направлении любого из соединений (ответ на запрос необязательно возвращается через то же соединение, которое содержало оригинальный запрос, хотя чаще всего именно так; как бы то ни было, ни в коем случае сообщение не может вернуться через соединение, принадлежащее другой сессии). Когда используется протокол UDP, ответ на запрос должен быть отправлен с помощью другого IP адреса, а не с того, с которого был послан запрос.

Есть несколько типов сообщений:

  • RPC вызовы (от клиента к серверу): обращается к методам API
  • RPC ответы (от сервера к клиенту): результаты RPC вызовов
  • подтверждение получения сообщения (или, точнее, уведомление о статусе группы сообщений)
  • запрос статуса сообщения
  • сообщение из нескольких частей или контейнер (контейнер, который содержит несколько сообщений; который должен послать несколько RPC вызовов за раз посредством соединения HTTP, например; также, контейнер может поддерживать gzip).

С точки зрения нижних уровней протокола, сообщение является потоком двоичных данных, выровненных по границе 4- или 16- байт.

Каждое сообщение, как отдельное так и состоящее в контейнере, состоит из идентификатора сообщений (64 бита, см. ниже), порядкового номера сообщения в сессии (32 бита), длины (тела сообщения в байтах; 32 бита), и тела (любого размера, кратного 4 байтам). В дополнение, когда контейнер или одиночное сообщение отправлено, вверху добавляется внутренний заголовок (см. ниже), затем всё сообщение шифруется, и внешний заголовок размещается вверху сообщения (64-битный идентификатор ключа и 128-битный ключ сообщения).

Тело сообщения обычно состоит из 32-битного типа сообщения, сопровождаемого зависимыми от типа параметрами. В частности, каждая функция RPC имеет соответствующий тип сообщения. Больше деталей по ссылке — Двоичная сериализация данных, Служебные сообщения.

Все числа записываются в кодировке little endian. Однако очень большие числа (2048-битные) использованные в RSA и DH записываются в формате big endian, т.к. это делает библиотека OpenSSL.

Авторизация и шифрование

Прежде чем сообщение (или сообщение из нескольких частей) будет передано через сеть с использованием транспортного протокола, оно шифруется определённым образом, и вверху сообщения добавляется внешний заголовок, который представляет собой: 64-битный идентификатор ключа (который уникально идентифицирует ключ авторизации для сервера, а также для юзера) и 128-битный ключ сообщения. Ключ юзера вместе с ключом сообщения определяет актуальный 256-битный ключ, который шифрует сообщение, используя AES-256 шифрование. Обратите внимание, что исходная часть сообщения, которая должна быть зашифрована, содержит непостоянные данные (сесия, ID сообщения, порядковый номер сообщения, соль сервера) которые очевидно влияют на ключ сообщения (и таким образом гп AES ключ и iv). Ключ сообщения определяется как 128 битами нижнего порядка от SHA1 тела сообщения (включающего ID сессии и сообщения и т.д.) Сообщения из неск. частей шифруются как одно сообщение.

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

Примечание от переводчика: по некоторым сведениям, в последних обновлениях этот ключ меняется через каждые 100 отправленных сообщений — https://twitter.com/durov/status/539489480676085760

Главным недостатком протокола является то, что нарушитель может присвоить ключ авторизации (например, украв девайс) и сможет расшифровать все принятые сообщения пост фактум. Возможно, это не такая уж большая проблема (украв девайс, нарушитель также получает доступ ко всей информации, кэшированной на девайсе даже не расшифровывая ничего); тем не менее, следующие шаги могут быть предприняты для преодоления этого недостатка:

  • ключи сессии, сгенерированные посредством протокола Диффи-Хеллмана и используемые вместе с ключами авторизации и сообщения для выбора параметров AES. Чтобы создать их, первое, что должен сделать клиент после создания новой сессии — это отправить специальный RPC запрос серверу («сгенерировать ключ сессии») на который сервер ответит, после чего все последующие сообщения в сессии будут также зашифрованы с помощью ключа сессии.
  • защитите ключ, сохранённый на девайсе с приложением с помощью (текстового) пароля; этот пароль не сохраняется в памяти и вводится юзером при входе в приложение или чаще (в зависимости от настроек приложения).
  • Данные, сохранённые (кэшированные) на девайсе юзера могут также быть защищены с помощью шифрования, использующего ключ авторизации, который, в свою очередь, может быть защищён паролем. После этого пароль потребуется даже для доступа к этим данным.

Синхронизация времени

Если время клиента сильно расходится со временем сервера, сервер может начать игнорировать сообщения клиента, или наоборот, из-за недействительного идентификатора сообщений (который тесно связан со временем создания). В этих условиях, сервер будет отправлять клиенту специальное сообщение, содержащее правильное время, и определённая 128-битная соль (salt) (или эксплицитно предоставленный клиентом в специальном запросе RPC синхронизации, или эквивалентный ключу последнего полученного от клиента сообщения за текущую сессию). Это сообщение может быть первым в контейнере, который включает другие сообщения (если расхождение времени значительно, но не ведёт к игнорированию сообщений клиента).

Получая такое сообщение или контейнер, содержащий его, клиент сначала выполняет синхронизацию времени (фактически, просто запоминая разницу между временем сервера и своим собственным, чтобы иметь возможность вычислить «правильное» время в будущем) и затем проверяет идентификатор сообщения на правильность.

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

Транспорт (передача)

Включает доставку зашифрованных контейнеров вместе с внешним заголовком (здесь и далее — Payload) от клиента к серверу и обратно. Есть три типа передачи:

  • HTTP
  • TCP
  • UDP

Мы исследуем первые два типа.

Передача по HTTP

Осуществляется через HTTP/1.1 (постоянное HTTP-соединение), работает под традиционным TCP Port 80 (TCP портом 80). HTTPS не используется, вместо этого используется упомянутый выше метод шифрования.

Соединение HTTP прикреплено к сессии (или скорее к идентификатору сессии+ключа), указанной в последнем полученном запросе юзера; обычно сессия одна и та же во всех запросах, но коварные HTTP прокси могут исказить это. Сервер может не вернуть сообщение в HTTP соединение, если оно не принадлежит к одной и той же сессии, и если не наступила очередь сервера (когда от клиента был получен HTTP запрос, на который ещё не был отправлен ответ).

Общий механизм следующий: клиент открывает одно или более постоянных HTTP-соединений с сервером; если должны быть отправлены одно или более сообщений, они объединяются под одним payload’ом, после которого следует POST запрос к URL/api к которому payload передаётся в виде данных. Кроме того, Content-Length, Keepalive, и Host являются действующими HTTP заголовками.

Получая запрос, сервер может или подождать некоторое время (если запрос требует ответа после короткого тайм-аута) или немедленно вернуть макет ответа (dummy response) (лишь подтверждая получение контейнера). В любом случае, ответ может содержать любое количество сообщений. Сервер может одновременно отправлять любые другие сообщения, которые содержит сессия.

Дополнительно, существует специальная очередь ожидающих RPC запросов (действующая только для HTTP соединений), которая передаёт/справляется с максимальной задержкой Т. Если у сервера есть сообщения для сессии, они возвращаются немедленно, в противном случае, включается режим ожидания до того времени, пока у сервера есть сообщение для клиента, или пока не пройдёт Т секунд. Если ничего не происходит за Т секунд, возвращается макет ответа.

Если серверу нужно послать сообщение клиенту, он проверяет HTTP соединение, которое принадлежит к нужной сессии и находится в состоянии «ответ на HTTP запрос» (включая очередь запросов), после чего сообщение добавляется к контейнеру ответа и отправляется юзеру. В типичном случае, есть некое дополнительное время ожидания (50 миллисекунд) на случай, что у сервера скоро будет больше сообщений для сессии.

Если нет подходящего доступного HTTP соединения, сообщения помещаются в очередь отправки текущей сессии. Однако они найдут свой путь до того как получение будет прямо или косвенно подтверждено сервером. Для HTTP протокола, отправка следующей очереди в том же HTTP соединении считается подтверждением (с этого момента HTTP протокол больше не требует, чтобы подтверждение было отправлено); в других случаях, клиент должен отправить точное подтверждение в течение допустимого времени (оно может быть добавлено к контейнеру для следующего запроса).

ВАЖНО. Если подтверждение не пришло вовремя, сообщение может быть отправлено заново (возможно, в другом контейнере). Объекты должны быть автономно подготовлены к этому и должны сохранить (записать) идентификаторы самых последних принятых сообщений (и игнорировать дубликаты, а не повторять действия). Чтобы не хранить идентификаторы вечно, существуют специальные сообщения-«сборщики мусора», которые пользуются однообразием идентификаторов сообещний.

Если отправленная очередь переполняется или если сообщения остаются в очереди дольше 10 минут, сервер забывает их (или отправляет в своп (swap), ничего особенного сдесь делать не требуется). Это может произойти даже быстрее, если у сервера закончилось буферное пространство (например, потому что серьёзные проблемы с сетью привели к большому количеству разорванных соединений).

TCP-транспорт

Очень схожа с передачей HTTP. Может так же быть осуществлена посредством порта 80 (чтобы проникнуть через все фаерволы) и даже использовать те же сервера IP адресов. В этой ситуации, сервер понимает, какой протокол нужно использовать — HTTP или TCP — основываясь на первых четырёх входящих байтах (для HTTP это POST).

Когда создано TCP-соединение, оно приписывается сессии (и ключу авторизации), переданной в первом сообщении юзера, и в дальнейшем используется исключительно для этой сессии (составные механизмы не разрешены).

Если payload (пакет) нужно передать от сервера к клиенту или от клиента к серверу, это выражается таким образом: 4 байта длины добавляются впереди (содержащие в себе длину, порядковый номер и CRC32; всегда делятся на 4) и 4 байта с порядковым номером пакета внутри TCP-соединения (первый отправленный пакет нумеруется как 0, следующий — как 1, и т.д.) и 4 CRC32 байта в конце (длина, порядковый номер, и payload вместе).

Есть сокращённая версия этого же протокола: если клиент отправляет 0xEF как первый байт (важно: только перед самым первым пакетом данных), то тогда длина пакета кодируется одним байтом (0x01..0x7E = длина данных разделённая/ делящаяся на/ кратная 4; или 0x7F после которого следуют 3 байта длины (little endian) кратным 4) после чего следуют собственно данные (порядковый номер и CRC32 не добавляется). В этом случае ответы сервера выглядят точно так же (сервер не отправляет 0xEF как первый байт).

В случае, если требуется выравнивание 4-байтовых данных, может быть использована промежуточная версия оригинального протокола: если клиент отправляет 0xEEEEEEEE как первый инт (int) (четыре байта), то длина пакета зашифрована всегда четырьмя байтами как в оригинальной версии, но порядковый номер и CRC32 опускаются, таким образом уменьшая итоговый /общий размер пакета на 8 байт.

Полная, промежуточная и сокращённая версии протокола поддерживаются для быстрого подтверждения. В этом случае клиент устанавливает бит длины наивысшего порядка в пакет запроса, и сервер отвечает специальными четырьмя байтами в виде отдельного пакета. Это 32 бита SHA1 высшего порядка зашифрованной части пакета, с самым важным / значимым битом, установленным, чтобы пояснить, что это не длина обыкновенного пакета ответа сервера; если используется упрощённая версия, для этих четырёх байт применяется bswap.

Не существует неявного / скрытого подтверждения для TCP-передачи: все сообщения должны быть подтверждены точно. Чаще всего подтверждения помещают в контейнер с следующим запросом или ответом, если он передаётся в упрощённом порядке. Например, это почти всегда происходит с сообщениями клиента, содержащими RPC-запросы: подтверждение обычно приходит вместе с RPC-ответом.

В случае ошибки, сервер может отправить пакет в котором payload состоит из 4 байт, которые являются кодом ошибки. Например, Код Ошибки 403 соответствует ситуациям, когда сответствующая ошибка HTTP возвращена HTTP-протоколом.

Комментарии