Безопасность WebRTC: DTLS, SRTP, fingerprints, identity

TL;DR

Любой звонок WebRTC шифрует медиа между двумя браузерами сквозным шифрованием – не как опцию, которую можно включить или выключить, а как неотъемлемое свойство, которое стандарт не позволяет отключить. Шифрование выполняется с помощью Secure RTP (SRTP), описанного в RFC 3711; ключи для SRTP согласуются в рамках небольшого TLS-рукопожатия поверх UDP – то есть с использованием Datagram Transport Layer Security (DTLS) – а расширение use_srtp из RFC 5764 связывает эти ключи между собой. Проверка подлинности – гарантия того, что вы действительно соединяетесь с тем, кого хотели вызвать, а не с злоумышленником, подслушивающим в середине канала, – осуществляется через обмен SHA-256-отпечатками DTLS-сертификатов в рамках протокола описания сессии (Session Description Protocol, SDP), как описано в RFC 5763 и архитектуре безопасности WebRTC в RFC 8827. Эта модель надёжно защищает от пассивных прослушивающих и большинства активных атак, однако полностью зависит от подлинности сигнального канала – именно поэтому та же архитектура требует использования HTTPS для страницы, применяющей WebRTC, и, опционально, стороннего провайдера идентификации (IdP) для криптографической проверки между разными доменами (origins).

Почему это важно

Если вы разрабатываете WebRTC-продукт – телемедицинскую консультацию, онлайн-урок в e-learning, видеоконференц-зал, контакт-центр, платформу для live-торговли, инструмент удалённой совместной работы или ИИ-агента с голосовым и видеоинтерфейсом, – безопасность не сводится к галочке в security review. Она заложена в каждый передаваемый пакет и в каждую строку SDP, с которой обмениваются ваши инженеры. Уверенный продакт-менеджер, основатель или заказчик должен чётко отвечать на четыре ключевых вопроса: что именно зашифровано, откуда берутся ключи, что злоумышленник на сигнальном канале может сделать и чего не может, и где end-to-end-шифрование (E2EE) перестаёт быть бесплатным и требует реализации на уровне приложения. Эта статья отвечает на эти вопросы для нетехнической аудитории и указывает старшему инженеру соответствующие разделы RFC, по которым каждое утверждение можно проверить.

Что WebRTC шифрует, а что – нет

Звонок WebRTC передаёт три разных типа байтов через публичный интернет, и стандарт по-разному обрабатывает каждый из них.

Первый – это медиа-плоскость: аудио- и видеокадры самой связи. Каждый кадр упаковывается в RTP-пакет, шифруется с помощью SRTP и передаётся по протоколу UDP. SRTP в WebRTC не является опциональным: спецификация W3C называет его обязательным, а в браузерном API отсутствует переключатель для его отключения. Даже если ваше приложение представляет собой локальное демо между двумя вкладками одного Chrome, медиа всё равно шифруется при передаче через UDP-сокет.

Второй – это сигнальная плоскость: SDP offer/answer, обмен ICE-кандидатами и любой служебный чат, который настраивает звонок. У WebRTC нет встроенного транспорта для сигнала: канал выбирает приложение – WebSocket, HTTPS или даже long-poll-эндпоинт, – а стандарт требует, чтобы этот канал был аутентифицированным и конфиденциальным, то есть на практике – HTTPS или WSS. Если сигнальный канал передаётся в открытом виде, атакующий на пути может подменить SDP, изменить отпечаток и провести атаку man-in-the-middle на DTLS ещё до начала передачи медиа.

Третий – это data channel: опциональный RTCDataChannel для произвольных данных приложения, используемый в инструментах совместной работы, многопользовательских играх и файлообмене. Data channel едет по той же DTLS-ассоциации, что ключует SRTP, и наследует те же свойства шифрования.

WebRTC не шифрует данные на уровне выше браузерного API. Если ваше приложение обрабатывает аудио для транскрипции на сервере перед отправкой во второй браузер, безопасность этого пути – ваша ответственность. Если приложение записывает звонок на диск, запись остаётся в открытом виде, пока вы её не зашифруете. И если звонок проходит через Selective Forwarding Unit (SFU) – а это характерно для почти любой конференции из трёх и более участников – SFU получает расшифрованные медиа, пока вы не реализуете сквозное шифрование на прикладном уровне (например, с помощью SFrame, см. ниже). Подробнее о SFU – в SFU, MCU, Mesh: три топологии WebRTC.

Нажмите, чтобы увеличить

SRTP простыми словами

SRTP – Secure Real-time Transport Protocol – описан в RFC 3711, опубликованном в марте 2004 года авторами Baugher, McGrew, Naslund, Carrara, Norrman. Это профиль RTP, то есть расширение, добавляющее три свойства поверх стандартного RTP-заголовка: конфиденциальность (полезная нагрузка зашифрована), аутентификацию (короткий тег в конце каждого пакета позволяет получателю убедиться, что пакет не был изменён) и защиту от replay-атак (индекс внутри пакета не даёт злоумышленнику сохранить старый пакет и отправить его повторно).

Исходный RFC 3711 описывает использование AES в режиме счётчика (AES-CTR) для шифрования и HMAC-SHA1 для создания тега аутентификации. Эта комбинация сегодня считается устаревшей. Современные реализации WebRTC предпочитают AEAD-шифры AEAD-128-GCM и AEAD-256-GCM – алгоритмы аутентифицированного шифрования с дополнительными данными, добавленные в SRTP согласно RFC 7714 (декабрь 2015). AEAD означает «аутентифицированное шифрование с дополнительными данными» – оно выполняется за один проход с одним ключом, что делает его быстрее на современных процессорах и проще в анализе. Возможности RTCRtpReceiver.getCapabilities('audio').codecs W3C и настройки srtp-context внутри libwebrtc показывают, какие профили поддерживаются; к 2026 году GCM станет стандартным выбором в каждом современном браузере.

SRTP сам по себе не определяет, откуда берётся ключ шифрования. Его генерирует какой-то другой протокол, а SRTP просто использует полученный результат. В WebRTC таким протоколом является DTLS, а связь между ними – use_srtp, расширение DTLS, описанное в RFC 5764.

Два момента про SRTP, которые удивляют неинженеров, стоит отметить:

Первый – сам RTP-заголовок не шифруется, шифруется только полезная нагрузка. Sequence number, timestamp и SSRC (Synchronisation Source) видны всем на пути. Это сделано намеренно: сети нужны эти поля, чтобы выполнять свою работу – пейсинг, работу jitter-буфера, обратную связь для управления перегрузками, см. Оценка полосы и congestion control в WebRTC. Скрыты содержание речи и пиксели изображения.

Второй – тег аутентификации короткий: обычно 80 бит для аудио (10 байт на пакет) и 32 бита для видео. Восемьдесят бит – сознательный компромисс: достаточно длинный, чтобы подделка стала непрактичной, и достаточно короткий, чтобы не «съесть» битрейт 20-милисекундного аудиопакета. RFC 3711 явно фиксирует этот выбор и его обоснование.

DTLS: TLS, переживший полёт по UDP

DTLS – Datagram Transport Layer Security – это версия TLS, работающая поверх UDP вместо TCP. WebRTC требует UDP для передачи медиа: из-за head-of-line blocking в TCP реальное аудио и видео будут страдать (подробнее см. TCP и UDP в стриминге), но при этом необходимы механизмы защиты, которые обеспечивает TLS-рукопожатие: взаимная аутентификация, согласование набора шифров и генерация сессионных ключей. DTLS – логичный выбор. Текущая версия – DTLS 1.3, RFC 9147, опубликованный в апреле 2022 года; предыдущая версия, DTLS 1.2 (RFC 6347, 2012), всё ещё используется в продакшене, но постепенно выводится из эксплуатации. NSS в Firefox и BoringSSL в Chromium перейдут на DTLS 1.3 к 2026 году; в libwebrtc переключение на него по умолчанию произошло в течение 2025 года.

Хендшейк DTLS в WebRTC-звонке проходит по тому же медиа-пути, а не по сигнальному каналу. Именно это свойство делает архитектуру целостной: как только ICE выбрала пару кандидатов (рабочие адреса с каждой стороны, см. NAT, STUN, TURN, ICE в WebRTC), два конечных узла обмениваются ClientHello и ServerHello UDP-датаграммами по этой паре, согласуют набор шифров, выполняют обмен ключами и завершают хендшейк – по тому же UDP-сокету, по которому будет передаваться медиа. Хендшейк занимает один round-trip в DTLS 1.3 (в 1.2 было два), так что плата за «зашифрованный» режим вместо «открытого» в WebRTC – это один RTT задержки при настройке и несколько сотен байт одноразового трафика.

Как DTLS устанавливает SRTP

Это момент, когда два протокола объединяются в один. Во время DTLS-рукопожатия обе стороны согласовывают расширение use_srtp из RFC 5764. Оно позволяет каждой стороне объявить поддерживаемые SRTP-профили (SRTP_AEAD_AES_128_GCM, SRTP_AES128_CM_HMAC_SHA1_80 и т. д.) и выбрать один из них. После завершения рукопожатия ни одна из сторон не использует DTLS-ключи приложения напрямую для SRTP. Вместо этого они применяют TLS Key Material Exporter (RFC 5705) с фиксированной строкой-меткой, чтобы получить детерминированный блок байтов из DTLS master secret. Этот блок делится на SRTP master key и SRTP master salt для направления «клиент → сервер» и на аналогичный блок для направления «сервер → клиент». Эти две пары ключей и используются SRTP-контекстом для шифрования и расшифровки всех последующих медиа-пакетов.

Что в этой схеме элегантно – ключи SRTP никогда не передаются по сигнальному каналу. Сигнальный сервер их не видит. SDP offer и answer их не содержат. Они вычисляются локально на каждом конце после DTLS-рукопожатия, безопасность которого зависит от сертификатов конечных точек, а не от информации, передаваемой по сигнальному каналу. Именно это свойство делает WebRTC принципиально надёжнее старого подхода SDES (Session Description Protocol Security Descriptions), в котором SRTP-ключи передавались прямо внутри SDP – и который спецификация WebRTC прямо запрещает.

Нажмите, чтобы увеличить

Fingerprint: как SDP связывает медиа-канал и сигнальный канал

Если DTLS активирует SRTP на медиа-канале, а сигнальный канал никогда не передаёт SRTP-ключи, то как вообще сигнал может быть важен для безопасности? Ответ – атрибут a=fingerprint в SDP, описанный в RFC 5763 (с базовым механизмом в RFC 4572).

Когда эндпоинт WebRTC генерирует свой DTLS-сертификат (браузеры делают это автоматически и один раз – свежий самоподписанный сертификат для каждого RTCPeerConnection), он вычисляет хеш сертификата с помощью SHA-256 и записывает этот хеш в SDP, который затем отправляет. Строка выглядит так:

a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2

Когда позже по медиа-каналу проходит DTLS-рукопожатие, каждый узел проверяет сертификат, представленный другой стороной: вычисляет для него SHA-256 и сравнивает с отпечатком, полученным в SDP. Если значения совпадают – узел общается с той же стороной, чей отпечаток был передан по сигнальному каналу. Если нет – соединение разрывается.

Это сравнение и составляет всю проверку идентичности в стандартном WebRTC-звонке. Оно связывает медиа- и сигнальную плоскости: атакующий, способный перехватывать и изменять SDP в реальном времени, может подменить свой отпечаток, завершить DTLS-рукопожатие со своей стороны, затем – с настоящим получателем вызова и остаться незамеченным посредником. Поэтому спецификация WebRTC требует, чтобы сигнальный канал был аутентифицирован и защищён – то есть на практике использовал HTTPS или WSS. Отпечаток – это мост; HTTPS – перила, не дающие его подменить.

Криптографический выбор SHA-256 имеет большое значение. RFC 8122 (обновляющий RFC 4572) прямо запрещает использование MD5 и SHA-1 для fingerprint’ов в новых реализациях; если вы видите fingerprint sha-1 в SDP современного браузера, это означает, что реализация устарела. Современные версии Chromium и Firefox по умолчанию используют sha-256 и отказываются от согласования более слабых хеш-функций.

Тонкость, которую стоит знать: сертификат самоподписанный и одноразовый. Он не выдан публичным центром сертификации, в нём отсутствует DNS-имя в поле common name, а срок его действия обычно ограничен временем RTCPeerConnection. Единственная его задача – предоставить публичный ключ, хеш которого совпадает с fingerprint для проверки. Этого достаточно, потому что полная проверка подлинности целиком делегирована сигнальному каналу, которому браузер уже доверяет – ведь страницу он получил по HTTPS.

Модель угроз: что атакующий может и чего не может

RFC 8826 – Security Considerations for WebRTC – описывает модель угроз с уровнем детализации, которого не найти ни в одном другом медиа-протоколе. Краткая сводка с практическими выводами для продуктовой команды:

Пассивный слушатель на медиа-пути видит зашифрованные SRTP-пакеты и почти ничего не узнаёт о содержании звонка. Он может определить IP-адреса, частоту пакетов в секунду, размер каждого пакета (что косвенно указывает на кодек и битрейт; наличие voice activity detection можно выявить по таймингу пакетов) и незашифрованные поля RTP-заголовка. Однако аудио прочитать или видео посмотреть он не может.

Пассивный слушатель на сигнальном пути, если сигнальный канал не использует HTTPS, может увидеть весь SDP – включая fingerprint. Сам по себе fingerprint не позволяет расшифровать трафик, поскольку SRTP-ключи генерируются на медиа-канале через DTLS exporter и не передаются в SDP. Однако SDP содержит IP-адреса, ICE-кандидаты и идентификаторы пользователей – это приводит к утечке информации о структуре вызовов.

Активный атакующий на медиа-пути может перехватывать, изменять и подменять пакеты. Тег аутентификации SRTP не позволит принять поддельные пакеты за легитимные. Окно защиты от повторной передачи (replay) не даст использовать сохранённый старый пакет позже. Самое серьёзное, что атакующий может сделать на этом пути, – это вызвать отказ в обслуживании (DoS): сделать звонок непригодным для использования, но не выдать себя за одну из сторон.

Активный атакующий на сигнальном пути – опасный сценарий – может изменять SDP, подменять fingerprint и осуществлять атаку «человек посередине», пока сигнальный канал не аутентифицирован. Это атака, описанная в §4.2 RFC 8826. Защита – использование HTTPS для веб-страницы и HTTPS/WSS для сигнального эндпоинта. Без них вся архитектура DTLS-SRTP оказывается уязвимой на уровне сигнальной плоскости: медиашифрование происходит между атакующим и каждой жертвой, а не между самими жертвами.

Злонамеренный собеседник – человек на другом конце звонка – может записать всё, что вы ему отправляете, и позже опубликовать, использовать в deepfake-генерации или хранить вечно. SRTP от этого не защищает, как и ни один другой медиа-протокол: решая поговорить с кем-то, вы должны осознавать, что переданные данные остаются у собеседника.

Злонамеренный SFU в multi-party-звонке, проходящем через сервер, видит расшифрованное медиа, поскольку сам завершает SRTP-контекст. Это структурный пробел, из-за которого нарушается E2EE – см. раздел SFrame ниже.

Кросс-оригинальный атакующий – сайт, стремящийся незаметно включить чужой микрофон и камеру, – блокируется моделью разрешений getUserMedia от W3C. Архитектура безопасности WebRTC рассматривает разрешение на доступ к локальным медиа как единственный и самый важный «гейт согласия», а модель «приглашение при первом использовании» является сознательной частью защитной конструкции.

Неизвестный key-share: тонкая атака, о которой стоит знать

Документ IETF 2020 года, RFC 8844, описал атаку «unknown key-share» на DTLS-SRTP. Сценарий: вредоносный пользователь A, желающий убедить пользователя C, что некий звук пришёл от пользователя B, договаривается о звонке и с B, и с C с одним и тем же fingerprint и пересылает медиа от B к C. C видит валидный DTLS-хендшейк против fingerprint, который ожидал, но говорящий – другой. Митигация – атрибут SDP tls-id (RFC 8842) и более сильный внешний идентификатор сессии, поддерживаемый современными реализациями (иногда называемый «уникальностью self-signed сертификата»). Атака экзотична на практике, но знать её стоит, если в вашей модели угроз есть враждебные собеседники.

Нажмите, чтобы увеличить

Identity: часть спецификации, которую почти никто не читает

RFC 8827 – WebRTC Security Architecture – также определяет опциональный identity-слой поверх DTLS-SRTP, отражённый в спецификации W3C WebRTC Identity. Идея заключается в том, чтобы сделать WebRTC-звонок криптографически атрибутируемым через границы origin: если пользователь на acme.example звонит пользователю на globex.example, каждая сторона может доказать другой (и браузеру) свою идентичность, подтверждённую сторонним провайдером идентификации (IdP), а не самим сайтом.

Механизм: каждый эндпоинт загружает JavaScript-фрагмент со своего IdP (Google, исторически Mozilla Persona, OAuth-провайдер). IdP подписывает отпечаток (fingerprint) в SDP токеном, привязанным к идентичности пользователя в IdP. Получающая сторона запрашивает у IdP проверочный скрипт, проверяет подпись и убеждается, что «этот отпечаток действительно принадлежит alice@example.com». В браузере это RTCPeerConnection.setIdentityProvider().

На практике этого почти никто не использует. В секции благодарностей RFC 8826 прямо указано, что механизм IdP не получил широкого распространения. Причины таковы: большинство реальных WebRTC-решений работают в рамках одного доверенного домена (приложения одной и той же компании с обеих сторон), поэтому междоменная идентификация не требуется; модель загрузки IdP оказывается навязчивой и хрупкой; альтернативные подходы к идентификации – серверная аутентификация сигнального WebSocket, JWT-токены, передаваемые через SDP a=-атрибуты – решают те же задачи с меньшими усилиями. По состоянию на 2026 год IdP-API присутствует в браузерах, но полноценный WebRTC-продукт можно создать, ни разу не воспользовавшись этим API.

Что разворачивают вместо этого

Шаблон, который ставится в проде: приложение аутентифицирует пользователя на сигнальном сервере (OAuth, SSO, magic-link – что используется в остальном продукте), затем выдаёт короткоживущий JWT или подобный токен, который WebRTC-клиент предъявляет SFU перед тем, как ему разрешат публиковать или подписываться. SFU обеспечивает политику – кто может присоединиться к какой комнате, кто может публиковать какой трек, кто с кем может говорить. Уровень DTLS-SRTP снизу даёт криптографическую защиту медиа; уровень приложения сверху даёт identity. LiveKit, mediasoup, Janus, Jitsi и любой коммерческий вендор SFU (Twilio, Dolby, Cloudflare, AWS IVS) документируют этот шаблон; страница про WebRTC-архитектуру по адресу /services/webrtc-development тоже на нём базируется.

End-to-end-шифрование: пробел, который SRTP не закрывает

Двусторонний WebRTC-звонок действительно зашифрован end-to-end в строгом смысле: ключами SRTP обладают только два браузера, и единственный способ постороннему получить доступ к медиаданным – скомпрометировать один из них. Multi-party-звонок, идущий через SFU, – уже нет. SFU завершает SRTP-контекст, чтобы читать RTP-заголовки и направлять пакеты нужным участникам, и при этом видит расшифрованные данные – как минимум заголовки RTP, а в большинстве реализаций – и полную полезную нагрузку, необходимую для работы jitter-буфера и адаптации битрейта. С точки зрения пользователя утверждение «WebRTC шифруется» формально верно, но на практике вводит в заблуждение.

RFC 9605 – Secure Frame (SFrame), опубликованный в августе 2024 года, – это стандарт IETF, закрывающий этот пробел. SFrame шифрует каждый медиа-кадр до обёртки в RTP и SRTP с использованием ключа, недоступного SFU. SFU видит зашифрованные кадры внутри SRTP-пакетов, читает SRTP-заголовки, может пересылать пакеты, но не может расшифровать полезную нагрузку. Таким образом, end-to-end-шифрование между участниками становится возможным без потери способности SFU маршрутизировать трафик – SFU по-прежнему пересылает пакеты, но уже в виде зашифрованного текста (ciphertext).

В браузере SFrame реализуется поверх Insertable Streams (формально – WebRTC Encoded Transform), API для Worker, дающего JavaScript-доступ к закодированным кадрам до их передачи в SRTP на стороне отправителя и после извлечения из SRTP на стороне получателя. Полная поддержка есть в Chromium; в Safari и Firefox – частичная, на 2026 год. Управление групповыми ключами – кто получает какой SFrame-ключ и как он обновляется при присоединении или выходе участника – делегируется прикладному протоколу; типичный выбор в 2026 году – MLS (Messaging Layer Security), хотя в продакшене до сих пор часто используются кастомные схемы управления ключами. Google Meet внедрил SFrame-подобный E2EE в 2022 году; WebRTC-продукт Zoom использует собственный E2EE на схожих примитивах; сегодня крупные вендоры SFU предоставляют E2EE-хуки.

Для большинства продуктов вывод такой: рутинная конференц-связь – достаточно DTLS-SRTP; регулируемые сферы, такие как медицина или финансы – добавьте SFrame; маркетинговое заявление «никакой сервер не видит мои данные» – добавьте SFrame и задокументируйте управление ключами.

Где здесь Фора Софт

WebRTC, конференц-связь, телемедицина, e-learning, контакт-центры с видео, видеонаблюдение и live-shopping – ядро практики Фора Софт с 2005 года, более 250 запущенных проектов. Защита медиа-канала – стандартная практика: в каждом проекте по умолчанию используется DTLS-шифрование и SRTP, HTTPS терминируется на сигнальном шлюзе, а конфигурация SFU регулярно аудируется на предмет привязки доступа к комнатам через токены. End-to-end-шифрование – тема отдельная: большинству решений в live-shopping и потребительском сегменте SFrame не требуется; продуктам в телемедицине и регулируемых финансовых сферах – часто нужен; e-learning занимает промежуточную позицию, в зависимости от юрисдикции. Масштабируется шаблон: «DTLS-шифрование и SRTP для защиты транспорта, JWT-аутентификация для идентификации, SFrame – при необходимости E2EE через SFU, если модель угроз этого требует».

Распространённая ошибка в безопасности WebRTC

Главная производственная неудача, которую мы видим при ревью WebRTC-проекта, – не в медиа-стеке. Это сигнальный канал, реализованный поверх обычного WebSocket (ws://), а не secure WebSocket (wss://). На тестах звонок выглядит зашифрованным: SRTP работает, DTLS-рукопожатие завершается, консоль браузера сообщает о защищённом соединении. Команда ставит галочку и выпускает релиз. В продакшене атакующий, находящийся на той же Wi-Fi-сети или контролирующий промежуточный узел, может перехватить и изменить SDP, подменить отпечаток сертификата, провести два DTLS-рукопожатия – по одному с каждой жертвой – и незаметно ретранслировать весь медиапоток. DTLS-слой сообщает об успехе с обеих сторон, потому что сертификаты совпадают с (подменёнными) отпечатками в (изменённом) SDP. Защита – один символ: wss://. RFC 8827 чётко фиксирует это требование; проверка должна быть первым пунктом любого чек-листа безопасности перед релизом WebRTC.

Сравнение четырёх ключевых механизмов безопасности WebRTC

Правильный ответ почти для любого продукта – сумма первых пяти строк. Две нижние – условные: identity-провайдеры – когда важна межorigin-атрибуция; SFrame – когда SFU входит в модель угроз. Для шифрования транспорта во всех потоковых протоколах см. DTLS, SRTP, TLS, mTLS – шифрование для media; для общей архитектуры WebRTC – WebRTC без эзотерики.

Числовой пример: цена «зашифрована»

Стандартное возражение против шифрования – накладные расходы. Посчитаем для обычного WebRTC-звонка с аудио и видео.

Видеопоток H.264 в разрешении 720p со скоростью 1500 кбит/с, разбитый на RTP-пакеты объёмом около 1200 байт, формирует примерно 156 пакетов в секунду. SRTP добавляет 32-битный (4 байта) тег аутентификации для видео, поэтому «накладные расходы» при передаче по сети составляют:

156 пакетов/с × 4 байта = 624 байт/с = 5 кбит/с на теги аутентификации

Для аудиопотока Opus со скоростью 32 кбит/с, частотой 50 пакетов в секунду и 80-битным (10 байт) тегом:

50 пакетов/с × 10 байт = 500 байт/с = 4 кбит/с на теги аутентификации

Само шифрование выполняется in-place и не увеличивает объём данных – AES-CM и AES-GCM обрабатывают полезную нагрузку без изменений. В итоге разница между зашифрованным и открытым трафиком по каналу составляет около 9 кбит/с на 1,5-мегабитном звонке, то есть 0,6% от общего битрейта. Современные процессоры x86 и ARM поддерживают инструкции для работы с AES (AES-NI на x86, Cryptography Extensions на ARMv8): одно ядро способно шифровать сотни мегабит в секунду, поэтому нагрузка на CPU смартфона остаётся незначительной по сравнению с нагрузкой от декодирования видео. Одноразовый DTLS-рукопожатие добавляет один round-trip к времени установки соединения – обычно 30–150 мс – и несколько килобайт одноразового трафика.

Производственных причин отключать шифрование в WebRTC не существует. Их никогда не было. Стандарт этого не позволяет.

Ключевые выводы

• Медиа WebRTC всегда зашифровано с помощью SRTP; стандарт W3C не позволяет отключить это.
• DTLS-рукопожатие происходит по медиапути и обеспечивает обмен ключами SRTP через расширение use_srtp; сами ключи SRTP никогда не передаются по сигнальному каналу.
• Строка SDP a=fingerprint:sha-256 связывает сертификат медиапути с идентификатором на сигнальном уровне; для доверенной привязки обязательны HTTPS или WSS.
• Модель угроз описана в RFC 8826; наиболее распространённая проблема в продакшене – обычный ws://, а не уязвимости в медиастеке.
• Механизм IdP из RFC 8827 редко применяется на практике; в продакшене предпочитают аутентификацию на основе JWT.
• DTLS-шифрование SRTP обеспечивает end-to-end защиту в двухсторонних звонках, но не при использовании SFU; SFrame (RFC 9605) – стандарт IETF, закрывающий этот пробел.

Что читать дальше

• WebRTC без эзотерики – общая архитектура WebRTC и жизненный цикл звонка.
• DTLS, SRTP, TLS, mTLS – шифрование для media – шифрование в потоковых протоколах, включая не-WebRTC сценарии.
• SDP offer/answer подробно – где находится строка a=fingerprint и как offer/answer обрабатывает ротацию сертификатов.

Призыв к действию

• Поговорить с инженером по стримингу о вашем WebRTC-проекте: связаться с Фора Софт.
• Посмотреть наши кейсы в конференц-связи, телемедицине и live-штопинге: www.forasoft.com.
• Скачать чек-лист WebRTC Security Pre-Flight (28-позиционный чек-лист по 8 направлениям для проверки DTLS-SRTP, fingerprint, шифрования сигнала, mDNS и SFrame перед релизом): Скачать PDF.