Как выбрать безопасный мессенджер: 12 вопросов с опорой на доказательства

Мессенджер может показывать значок замка, называть себя приватным и при этом оставлять важные вопросы без ответа.

Какие разговоры зашифрованы? Защищены ли вложения? Где хранятся ключи? Какую информацию сохраняет сервер? Что происходит при потере устройства? Могут ли ключи шифрования измениться без предупреждения?

Эти подробности помогают увидеть и полезные меры защиты, и доказательства, которых пока не хватает. Ни один чек-лист сам по себе не подтверждает безопасность продукта.

В этом руководстве — 12 практических вопросов, которые стоит задать, прежде чем доверить зашифрованному мессенджеру личные разговоры, конфиденциальные файлы или чувствительную рабочую информацию.

Что такое безопасный мессенджер?

Безопасный мессенджер — сервис связи, предназначенный для защиты разговоров от несанкционированного доступа, перехвата, компрометации аккаунта и непреднамеренного раскрытия данных.

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

Для особо приватных разговоров он также должен предоставлять сквозное шифрование.

Сквозное шифрование, или E2EE, защищает поддерживаемое содержимое, шифруя его на устройстве отправителя и расшифровывая на устройстве авторизованного получателя. Сервис может доставлять зашифрованные данные, не нуждаясь в читаемом тексте сообщения.

Однако шифрование — лишь одна часть безопасности переписки.

Полная оценка должна также учитывать:

• Какие разговоры зашифрованы
• Получают ли фотографии и файлы такую же защиту
• Где хранятся закрытые ключи
• Как контакты могут проверять ключи
• Какие метаданные остаются видимыми
• Как работает восстановление аккаунта и ключей
• Что происходит при компрометации устройства
• Как сервис документирует свои ограничения

Для более подробного знакомства прочитайте объяснение сквозного шифрования.

Почему слова «зашифровано» недостаточно

Практически любой современный мессенджер шифрует сетевой трафик с помощью HTTPS, TLS или другого защищённого транспорта.

Эта защита важна, но не обязательно означает, что разговор защищён сквозным шифрованием.

При транспортном шифровании данные защищены во время передачи между вашим устройством и сервисом. Сервис всё ещё может получать читаемое содержимое, прежде чем передать его через другое защищённое соединение.

При E2EE поддерживаемое содержимое сообщений шифруется для участников до того, как попадёт в сервис.

Это различие определяет, кто технически может получить доступ к содержимому сообщения.

Поэтому нужно задавать точные вопросы, а не принимать общее обозначение «зашифровано».

Заявление	Вопрос, который стоит задать
«Ваши чаты зашифрованы»	Только при передаче или сквозным образом?
«Ваши данные в безопасности»	Какие данные, от каких угроз и на какой срок?
«Мы не можем читать ваши сообщения»	Относится ли это к личным чатам, группам, медиафайлам, звонкам и резервным копиям?
«Приватность заложена в архитектуру»	Какие метаданные и служебные сведения остаются доступными?
«Безопасное восстановление»	Кто может восстановить ключи шифрования и какой секрет требуется?

1. Какие разговоры защищены сквозным шифрованием?

Не предполагайте, что одно заявление о шифровании относится ко всем частям приложения.

Сервис может предоставлять разную защиту для:

• Личных разговоров один на один
• Закрытых групп
• Публичных групп
• Вещательных каналов
• Голосовых и видеозвонков
• Историй или временных публикаций
• Ботов и автоматизированных аккаунтов
• Синхронизированной истории переписки

Попросите провайдера указать точную границу.

Содержательный ответ выглядит так:

Текст личных сообщений и медиафайлы шифруются на устройствах участников. Совместимые закрытые группы защищены сквозным шифрованием LGS1 с автоматической ротацией ключей отправителя при изменениях состава. Каналы используют отдельную архитектуру с читаемым для сервера содержимым и не описываются как E2EE.

Слабый ответ выглядит так:

Ваше общение защищено шифрованием военного уровня.

Первый ответ даёт информацию, которую можно оценить. Второй использует впечатляющие слова, не определяя защищаемое содержимое или модель угроз.

2. Зашифрованы ли фотографии, видео и вложения?

Приложение может шифровать текст, но обрабатывать загруженные медиафайлы через другую систему.

Отсюда важный вопрос: шифруется ли фотография на стороне клиента до загрузки или защищена только серверными разрешениями и транспортным шифрованием?

Спросите о:

• Фотографиях и видео
• Документах
• Голосовых сообщениях
• Предварительных просмотрах ссылок
• Миниатюрах
• Временных файлах загрузки
• Кешированных медиафайлах
• Проверке прав при скачивании

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

Отдельно спросите о доступе к зашифрованным байтам и о доступе к ключу расшифрования. Некоторые архитектуры распространяют зашифрованные вложения через хранилище с менее строгими ограничениями; это не означает автоматического раскрытия открытого текста. Главный вопрос — может ли неавторизованная сторона получить читаемый медиафайл или его ключ и какие метаданные раскрывает путь хранения.

3. Где создаются и хранятся ключи шифрования?

Шифрование надёжно лишь настолько, насколько надёжно управление ключами.

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

Ищите ясные ответы на следующие вопросы:

• Создаётся ли закрытый ключ на устройстве?
• Загружается ли он когда-либо без шифрования?
• Может ли провайдер вычислить или заменить его?
• Может ли другое устройство, на котором выполнен вход, получить его автоматически?
• Защищено ли локальное хранилище ключей?
• Что происходит после сброса ключа?
• Создаёт ли переустановка приложения новый ключ идентичности?

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

4. Могут ли контакты проверять ключи друг друга?

Сквозное шифрование защищает разговор только тогда, когда ключи принадлежат предполагаемым участникам.

Многие безопасные системы представляют открытый ключ в виде отпечатка, номера безопасности, QR-кода или другого проверочного значения.

Два контакта могут сравнить это значение через доверенный канал, например:

• При личной встрече
• Во время проверенного голосового звонка
• Через ранее аутентифицированный аккаунт
• Через доверенный корпоративный справочник

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

Также спросите, что происходит при изменении отпечатка.

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

5. Какие метаданные сохраняет сервис?

Содержимое сообщений и их метаданные — разные категории.

Сервис может не иметь возможности читать тело E2EE-сообщения, но при этом обрабатывать сведения, необходимые для маршрутизации, синхронизации и отображения разговора.

В зависимости от системы это могут быть:

• Идентификаторы аккаунтов отправителя и получателя
• Состав участников разговора
• Временные отметки сообщений
• Подтверждения доставки и прочтения
• Размер сообщения
• События реакций и редактирования
• Сеансы устройств
• Курсоры синхронизации
• Материал открытых ключей
• Токены push-уведомлений
• Записи для предотвращения злоупотреблений и обеспечения безопасности

Наличие служебных метаданных не делает сервис автоматически небезопасным.

Важны следующие вопросы:

• Что собирается?
• Зачем это нужно?
• Как долго хранится?
• Кто имеет доступ?
• Может ли пользователь экспортировать или удалить эти данные?
• Используются ли они для рекламы или постороннего профилирования?

Будьте осторожны, когда провайдер утверждает, что «не хранит метаданные», не определяя, что он считает метаданными.

6. Как проходит аутентификация вашего аккаунта?

Сильное шифрование сообщений не компенсирует слабую защиту аккаунта.

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

Оцените, предоставляет ли сервис такие меры защиты, как:

• Безопасная обработка паролей
• Ограничение частоты запросов
• Отзыв сеансов
• Понятное управление устройствами или сеансами
• Защита от повторного воспроизведения учётных данных
• Безопасные процедуры сброса пароля
• Многофакторная аутентификация, где она уместна
• Уведомления о важных изменениях аккаунта

Также отличайте аутентификацию аккаунта от шифрования сообщений.

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

7. Как работает зашифрованное восстановление?

Восстановление создаёт один из самых сложных компромиссов в приватной переписке.

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

Защищённая схема восстановления может шифровать резервную копию на клиенте и требовать секрет восстановления, ключ доступа или одобрение доверенного устройства. Сначала выясните, что содержит копия: идентичность аккаунта, контакты и история сообщений — разные вещи.

Спросите:

• Шифруется ли копия до загрузки?
• Достаточно ли пароля аккаунта для её восстановления?
• Известен ли провайдеру секрет восстановления?
• Может ли поддержка сбросить этот секрет?
• Что происходит при потере секрета?
• Сохраняется ли после восстановления тот же отпечаток открытого ключа?
• Можно ли отключить восстановление?

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

Это последствие может свидетельствовать о реальной границе безопасности, а не о недостатке продукта.

8. Что происходит при обрыве соединения?

Безопасность и надёжность должны работать вместе.

Мобильные соединения пропадают. Браузеры засыпают. Устройства переключаются между сетями. Хорошо спроектированный мессенджер должен справляться с временными отключениями без дублирования сообщений, нарушения порядка или ослабления шифрования.

Ищите модель офлайн-работы и синхронизации, которая умеет:

1. Локально подготовить исходящее действие.
2. Присвоить ему устойчивый идентификатор.
3. Безопасно повторить попытку после восстановления соединения.
4. Избежать повторных отправок.
5. Согласовать состояние с подтверждением сервера.
6. Получить изменения, пропущенные во время отсутствия связи.

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

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

9. Как проверяются права на загрузки и хранящиеся объекты?

Безопасность медиафайлов включает не только шифрование.

Сервис может обрабатывать аватары, вложения сообщений, обои, истории, временные загрузки и созданные миниатюры. Каждому объекту нужна политика доступа.

Проверьте, выполняет ли приложение следующее:

• Требует аутентификацию для получения приватных медиафайлов
• Проверяет принадлежность запрашивающего аккаунта соответствующему разговору
• Отделяет публичные ресурсы от приватных объектов сообщений
• Удаляет загрузки, которые так и не были прикреплены
• Удаляет временные объекты с истёкшим сроком
• Предотвращает утечки через кеш между аккаунтами
• Использует непредсказуемые идентификаторы, не считая непредсказуемость разрешением доступа

Приватный незашифрованный файл не должен становиться читаемым лишь потому, что кто-то угадал его URL. Для зашифрованных объектов изучите, как распространяются и отзываются ключи и полномочия доступа. Рекомендации OWASP по авторизации советуют последовательно применять решения о доступе, в том числе к статическим ресурсам; один непредсказуемый идентификатор — не полноценная политика авторизации.

10. Защищены ли групповые чаты иначе?

Шифрование групп и управление составом участников порождают другие вопросы, чем шифрование личных чатов.

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

Одни сервисы предоставляют E2EE и для личных, и для групповых чатов. Другие используют E2EE только для личных разговоров, а группы защищают TLS, хранилищем с аутентификацией и серверным контролем доступа.

Вторая модель тоже может давать существенную защиту, но её граница доверия иная.

Спросите, может ли сервер обрабатывать содержимое группы и меняется ли защита, когда:

• Присоединяется участник
• Участник выходит
• Администратор кого-то удаляет
• Сообщение редактируется
• История синхронизируется на новое устройство
• В группу добавляется бот или интеграция

Никогда не предполагайте, что замок в одном типе разговора автоматически относится ко всем другим типам.

11. Какие настройки приватности доступны пользователю?

Приватность — это ещё и контроль после того, как информация попала в сервис.

Ищите практические возможности управления аккаунтом и разговором, например:

• Экспорт данных аккаунта
• Удаление аккаунта
• Отзыв сеансов
• Очистку локальной или синхронизированной истории
• Удаление отправленных сообщений, где это разрешено
• Управление подтверждениями прочтения
• Настройку видимости профиля
• Блокировку нежелательных контактов
• Управление предпросмотром уведомлений
• Отключение или удаление резервных копий ключей

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

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

12. Конкретны и проверяемы ли заявления о безопасности?

Лучшая документация по безопасности определяет границы.

Ищите конкретные сведения о:

• Алгоритмах и размерах ключей
• Операциях на клиенте и на сервере
• Типах разговоров, покрываемых E2EE
• Шифровании медиафайлов
• Сохраняемой информации
• Аутентификации
• Восстановлении
• Изменениях ключей
• Контроле доступа
• Известных ограничениях
• Дате последнего обновления документации

Осторожно относитесь к расплывчатым фразам:

• Невзламываемое шифрование
• Абсолютная приватность
• Безопасность военного уровня
• Полная анонимность
• Ноль метаданных
• Невозможно взломать
• Шифрование с гарантией на будущее

Ни одну сложную систему связи не стоит оценивать только по лозунгу.

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

Безопасная переписка: убедительные и тревожные признаки

Убедительный признак	Тревожный признак
Провайдер перечисляет разговоры с E2EE	Любая функция описана просто как «зашифрованная»
Объяснено, кто владеет закрытыми ключами	Управление ключами никогда не обсуждается
Изменения ключей заметны	Ключи могут меняться незаметно
Ограничения восстановления задокументированы	Поддержка может восстановить всё, не объясняя как
Перечислены категории метаданных	Провайдер заявляет «ноль метаданных» без определений
Защита медиафайлов описана отдельно	Упоминаются только текстовые сообщения
Для групп определена граница доверия	Создаётся впечатление, что заявления о личных чатах охватывают и группы
Страницы безопасности содержат актуальные детали реализации	Маркетинговые формулировки противоречат технической документации
Ограничения изложены ясно	Сервис заявляет абсолютную или невзламываемую защиту

Применяем чек-лист к публичным заявлениям Livara

Страница безопасности Livara содержит документацию продукта, а не независимую сертификацию. Её текущие границы различают:

• Личные сообщения: LVR1 использует гибридное согласование ключей P-256 и ML-KEM-768 и аутентифицированное шифрование поддерживаемого содержимого.
• Совместимые закрытые группы: защита ключами отправителя LGS1; состав участников и роли остаются отдельной границей полномочий сервера. Старые несовместимые группы не должны автоматически получать обозначение E2EE.
• Публичные каналы: читаемое сервером содержимое, не E2EE.
• Восстановление: материал идентичности криптографически запечатывается до загрузки; его восстановление не означает восстановления истории чатов.
• Метаданные и устройства: записи маршрутизации и скомпрометированные конечные устройства остаются за пределами обещания шифрования содержимого.

Рассматривайте это как заявления, которые нужно сверить с установленной версией и моделью угроз. Спецификация протокола, локальный тестовый вектор, аудит конкретной версии и наблюдение за работающим сервисом — разные формы доказательств. Не заменяйте недостающие свидетельства предположением ни об идеальной безопасности, ни о доказанной уязвимости.

Чек-лист безопасного мессенджера за 60 секунд

Прежде чем создавать аккаунт, проверьте, можете ли вы ответить на каждый вопрос:

• Какие типы разговоров защищены сквозным шифрованием?
• Входят ли в защиту изображения, видео, документы и голосовые сообщения?
• Создаются и хранятся ли закрытые ключи на устройствах участников?
• Могут ли контакты сравнить отпечатки ключей или номера безопасности?
• Заметны ли изменения ключей?
• Перечисляет ли политика приватности сохраняемые метаданные?
• Объяснена ли аутентификация аккаунта?
• Отделён ли процесс восстановления ключей от обычного входа?
• Проверяются ли подлинность и права запросов к приватным медиафайлам?
• Сохраняется ли шифрование во время ожидания в офлайн-очереди?
• Определена ли точная граница безопасности групп и каналов?
• Описаны ли ограничения без преувеличенных обещаний?

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

Но он должен давать достаточно точные ответы, чтобы пользователи понимали, чему доверяют.

Самый безопасный выбор зависит от вашей модели угроз

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

Семейной группе, рабочему коллективу, журналисту и источнику, медицинской команде и публичному сообществу могут требоваться разные сочетания:

• Конфиденциальности
• Проверки личности
• Анонимности
• Администрирования групп
• Хранения сообщений
• Соблюдения нормативных требований
• Восстановления
• Поддержки нескольких устройств
• Открытого исходного кода
• Независимого аудита
• Удобства использования

Начните с вопроса, что и от кого вы защищаете.

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

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

Шифрование не исправит скомпрометированное конечное устройство и не помешает доверенному получателю поделиться сообщением.

Приватность начинается с точных ожиданий

Надёжный мессенджер не просит пользователей поверить, что все риски исчезли.

Он объясняет:

• Что защищено
• На каких устройствах находятся ключи
• Что обрабатывает сервер
• Какие метаданные остаются
• Как работает восстановление
• Где E2EE начинается и заканчивается
• Какие меры защиты пока не реализованы

Эта ясность позволяет принимать обоснованные решения.

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

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

Частые вопросы

Что делает мессенджер безопасным?

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

Становится ли зашифрованный мессенджер автоматически приватным?

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

Скрывает ли сквозное шифрование, кому я пишу?

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

Может ли провайдер мессенджера восстановить E2EE-сообщения?

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

Безопасна ли защищённая переписка в браузере?

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

Всегда ли групповые чаты защищены сквозным шифрованием?

Нет. Одни сервисы предоставляют E2EE для групп, другие применяют его только к личным разговорам. Проверьте точную границу в документации провайдера.

Что происходит, если мой ключ шифрования меняется?

Смена ключа может быть вызвана новым устройством, переустановкой, сбросом ключа или восстановлением. Безопасный мессенджер должен показывать изменение и позволять контактам проверить новый отпечаток.

Достаточно ли E2EE для особо чувствительного общения?

E2EE защищает содержимое между поддерживаемыми конечными устройствами, но не защищает заражённое или разблокированное устройство, не гарантирует поведение получателя и не скрывает метаданные автоматически. Пользователям с повышенным риском также нужна сильная защита устройств и операционной деятельности.