Захищений дзвінок має більше ніж один шлях передавання даних. Сигналізація координує, хто телефонує і як з’єднуються кінцеві точки; медіаканал передає аудіо та відео. Захист одного шляху не захищає інший автоматично, і жоден із них сам по собі не приховує всі закономірності спілкування.
WebRTC надає важливі механізми безпеки, але повну межу приватності й далі визначають перевірки ідентичності в застосунку, ролі серверів і режим запису.
Сигналізація та медіадані виконують різні завдання
| Рівень | Типове призначення | Питання безпеки |
|---|---|---|
| Сигналізація | Запрошення, описи сеансів і кандидати з’єднання | Хто може читати або змінювати інформацію для встановлення зв’язку та як автентифікується потрібний співрозмовник? |
| Медіадані | Аудіо, відео та пов’язані потоки реального часу | Де завершується шифрування і які кінцеві точки можуть отримати доступ до медіаданих? |
| Службові записи | Маршрутизація, час з’єднань і стан доставлення | Які метадані може спостерігати сервіс або мережа? |
| Запис | Створення копії, що зберігається | Хто отримує відкритий текст або придатні до використання ключі запису й де зберігається копія? |
Протокол обміну повідомленнями може переносити зашифровану сигналізацію, але WebRTC не вимагає повсюдного використання формату оболонки якогось конкретного месенджера. Можливі й інші архітектури з автентифікацією.
Що забезпечує DTLS-SRTP
Архітектура безпеки WebRTC, RFC 8827, вимагає захисту медіаканалів та описує встановлення ключів DTLS-SRTP. Спрощено кажучи, DTLS допомагає встановити криптографічний контекст, а SRTP захищає медіапакети реального часу.
Кінцеві точки цього захисту мають значення. Пряме зашифроване з’єднання між учасниками відрізняється від з’єднання, що завершується на сервері обробки медіа. Деякі багатокористувацькі системи додають окремий наскрізний рівень поверх транспортного шифрування з’єднання із сервером. Саме слово «WebRTC» не повідомляє, яку архітектуру використовує продукт.
Чому важлива автентифікація сигналізації
Під час установлення дзвінка може передаватися інформація, що пов’язує медіаз’єднання з потрібним співрозмовником. Якщо зловмисник може непомітно підмінити її, шифрування здатне встановити захищене з’єднання не з тією кінцевою точкою.
RFC 8827 розглядає цей зв’язок між сигналізацією, ідентичностями та відбитками DTLS. HTTPS захищає з’єднання із сервісом сигналізації; сам по собі він не усуває потребу враховувати зловмисний або скомпрометований сервіс. Сигналізація з наскрізною автентифікацією або належний незалежний механізм перевірки співрозмовника можуть посилити цю межу.
Конфіденційність сигналізації — пов’язана, але окрема мета: вона обмежує коло тих, хто може прочитати подробиці встановлення зв’язку. Архітектура має пояснювати і конфіденційність, і автентифікацію, а не вважати зашифрований блок даних достатнім доказом обох.
Зашифрована сигналізація не робить дзвінок невидимим
Ретранслятор усе ще може знати, між якими обліковими записами або пристроями він спрямовує дані. Спостерігачі мережі можуть бачити час з’єднань, обсяг трафіку та адреси серверів. Співрозмовники або інфраструктура ретрансляції також можуть отримувати мережеву інформацію залежно від архітектури з’єднання.
Отже, шифрування запрошення до дзвінка не доводить, що сервіс не може зробити висновок про дзвінок, зіставити зв’язки між людьми або зберегти пов’язані з дзвінком записи. Приховування вмісту та приховування закономірностей трафіку — окремі завдання.
Опублікована межа захисту Livara
Сторінка безпеки Livara описує прямі й групові дзвінки як наскрізно зашифровані, але робить явний виняток для необов’язкового запису на сервері: доки активний видимий індикатор REC, дзвінок використовує транспортне шифрування, а не E2EE.
Її модель загроз також відкидає заяви про анонімність метаданих і захист від скомпрометованого пристрою. Це заяви про продукт, а не незалежна перевірка всіх шляхів дзвінка. Цей посібник не стверджує неперевіреного обмеження кількості учасників, формату сигналізації чи постквантової реалізації медіаканалу.
Зокрема, постквантовий обмін ключами в месенджері не оновлює автоматично окреме узгодження ключів медіаканалу WebRTC. Алгоритми та прив’язування ключів на шляху передавання медіа слід оцінювати незалежно.
Перед конфіденційним дзвінком
- Підтвердьте учасників і з’ясуйте причини несподіваних змін ідентичності.
- Перевірте, чи ввімкнено запис і що, за словами застосунку, через це змінюється.
- З’ясуйте, чи обробляє сервіс медіадані, чи лише пересилає захищені пакети.
- Враховуйте пристрої та приміщення навколо учасників: шкідливе ПЗ, захоплення екрана або слухач поруч можуть розкрити вміст після розшифрування.
- Запитуйте відомості про архітектуру й результати тестування саме того режиму, яким користуєтеся, замість того щоб покладатися на загальну позначку «зашифровані дзвінки».
Корисна заява про безпеку окремо вказує, хто може отримати доступ до сигналізації, медіаданих, метаданих і записів.
