Як обрати безпечний месенджер: 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 захищає вміст між підтримуваними кінцевими пристроями, але не захищає заражений або розблокований пристрій, не гарантує поведінки одержувача й не приховує метадані автоматично. Користувачам із підвищеним ризиком також потрібні надійна безпека пристроїв та операційна безпека.