У защищённого звонка несколько путей передачи данных. Сигнализация координирует, кто звонит и как соединяются конечные точки; медиаканал передаёт аудио и видео. Защита одного пути не защищает другой автоматически, и ни один из них сам по себе не скрывает все закономерности общения.
WebRTC предоставляет важные механизмы безопасности, но полную границу приватности по-прежнему определяют проверки идентичности в приложении, роли серверов и режим записи.
Сигнализация и медиаданные выполняют разные задачи
| Уровень | Типичное назначение | Вопрос безопасности |
|---|---|---|
| Сигнализация | Приглашения, описания сеансов и кандидаты соединения | Кто может читать или изменять информацию для установления связи и как аутентифицируется нужный собеседник? |
| Медиаданные | Аудио, видео и связанные потоки реального времени | Где завершается шифрование и какие конечные точки могут получить доступ к медиаданным? |
| Служебные записи | Маршрутизация, время соединений и состояние доставки | Какие метаданные может наблюдать сервис или сеть? |
| Запись | Создание сохраняемой копии | Кто получает открытый текст или пригодные для использования ключи записи и где хранится копия? |
Протокол обмена сообщениями может передавать зашифрованную сигнализацию, но WebRTC не требует повсеместного использования формата оболочки какого-либо конкретного мессенджера. Возможны и другие аутентифицированные архитектуры.
Что даёт DTLS-SRTP
Архитектура безопасности WebRTC, RFC 8827, требует защиты медиаканалов и описывает установление ключей DTLS-SRTP. Упрощённо говоря, DTLS помогает установить криптографический контекст, а SRTP защищает медиапакеты реального времени.
Конечные точки этой защиты имеют значение. Прямое зашифрованное соединение между участниками отличается от соединения, завершающегося на сервере обработки медиа. Некоторые многопользовательские системы добавляют отдельный сквозной уровень поверх транспортного шифрования соединения с сервером. Само слово «WebRTC» не говорит о том, какую архитектуру использует продукт.
Почему важна аутентификация сигнализации
При установлении звонка может передаваться информация, связывающая медиасоединение с нужным собеседником. Если злоумышленник может незаметно подменить её, шифрование способно установить защищённое соединение не с той конечной точкой.
RFC 8827 рассматривает эту связь между сигнализацией, идентичностями и отпечатками DTLS. HTTPS защищает соединение с сервисом сигнализации; сам по себе он не устраняет необходимость учитывать злонамеренный или скомпрометированный сервис. Сигнализация со сквозной аутентификацией или подходящий независимый механизм проверки собеседника могут укрепить эту границу.
Конфиденциальность сигнализации — связанная, но отдельная цель: она ограничивает круг тех, кто может прочитать детали установления связи. Архитектура должна объяснять и конфиденциальность, и аутентификацию, а не считать зашифрованный блок данных достаточным доказательством обеих.
Зашифрованная сигнализация не делает звонок невидимым
Ретранслятор всё ещё может знать, между какими аккаунтами или устройствами он направляет данные. Наблюдатели сети могут видеть время соединений, объём трафика и адреса серверов. Собеседники или инфраструктура ретрансляции тоже могут узнавать сетевую информацию в зависимости от устройства соединения.
Следовательно, шифрование приглашения к звонку не доказывает, что сервис не может сделать вывод о звонке, сопоставить связи между людьми или сохранить связанные со звонком записи. Скрытие содержимого и скрытие закономерностей трафика — разные задачи.
Опубликованная граница защиты Livara
Страница безопасности Livara описывает прямые и групповые звонки как сквозным образом зашифрованные, но делает явное исключение для необязательной записи на сервере: пока активен видимый индикатор REC, звонок использует транспортное шифрование, а не E2EE.
Её модель угроз также отвергает заявления об анонимности метаданных и защите от скомпрометированного устройства. Это заявления о продукте, а не независимая проверка всех путей звонка. Это руководство не заявляет о непроверенном ограничении числа участников, формате сигнализации или постквантовой реализации медиаканала.
В частности, постквантовый обмен ключами в мессенджере не обновляет автоматически отдельное согласование ключей медиаканала WebRTC. Алгоритмы и привязку ключей на пути передачи медиа необходимо оценивать независимо.
Перед конфиденциальным звонком
- Подтвердите участников и разберитесь с неожиданными изменениями идентичности.
- Проверьте, включена ли запись и что, по словам приложения, из-за этого меняется.
- Выясните, обрабатывает ли сервис медиаданные или только пересылает защищённые пакеты.
- Учитывайте устройства и помещения вокруг участников: вредоносное ПО, захват экрана или находящийся рядом слушатель могут раскрыть содержимое после расшифрования.
- Запрашивайте сведения об архитектуре и результаты тестирования именно того режима, которым пользуетесь, вместо того чтобы полагаться на общий значок «зашифрованные звонки».
Полезное заявление о безопасности отдельно указывает, кто может получить доступ к сигнализации, медиаданным, метаданным и записям.
