Безопасность 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 Security Architecture в RFC 8827. Эта модель надёжно защищает от пассивного слушателя и большинства активных атакующих, но она целиком зависит от подлинности сигнального канала – поэтому та же архитектура требует HTTPS для страницы, использующей WebRTC, и опционально – третьего identity provider (IdP) для криптографической межорigin-верификации.

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

Если вы поставляете WebRTC-продукт – телемедицинскую консультацию, прямой урок в e-learning, видеоконференц-зал, контакт-центр, площадку для live-shopping, инструмент удалённой совместной работы или голосо-видеоагента на ИИ, – безопасность не сводится к галочке на 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. Если ваше приложение обрабатывает аудио для транскрипции на сервере перед отправкой во второй браузер, этот путь – ваша ответственность. Если приложение пишет звонок на диск, запись – это plaintext, пока вы её не зашифруете. И если звонок идёт через Selective Forwarding Unit (SFU) – а это верно почти для любой конференции на трёх и более человек – SFU видит расшифрованное медиа, пока вы не добавите end-to-end-шифрование на прикладном уровне (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 в counter-режиме (AES-CM) для шифрования и HMAC-SHA1 для тега аутентификации. Эта связка сегодня считается устаревшей. Современные реализации WebRTC предпочитают AEAD-AES-128-GCM и AEAD-AES-256-GCM – Authenticated-Encryption-with-Associated-Data-шифры, добавленные в 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, см. Оценка полосы и 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 убьёт real-time-аудио и видео; см. TCP и UDP в стриминге), но при этом нужны защиты, которые даёт TLS-хендшейк: взаимное подтверждение идентичности, согласование cipher suite, выработка сессионных ключей. 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-датаграммами по этой паре, согласуют cipher suite, делают key exchange и завершают хендшейк – по тому же UDP-сокету, по которому пойдёт медиа. Хендшейк занимает один round-trip в DTLS 1.3 (было два в 1.2), так что цена «зашифровано» вместо «открыто» в WebRTC – это один RTT setup-задержки и несколько сотен байт одноразового трафика.

Как DTLS ключует SRTP

Это момент, в который два протокола становятся одним. Во время DTLS-хендшейка обе стороны согласуют расширение use_srtp из RFC 5764. Оно позволяет каждой стороне объявить, какие SRTP-профили она поддерживает (SRTP_AEAD_AES_128_GCM, SRTP_AES128_CM_HMAC_SHA1_80 и т. д.) и выбрать один. Когда хендшейк завершён, ни одна из сторон не использует DTLS application keys напрямую для 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-сертификат (браузеры делают это автоматически и одноразово – свежий self-signed сертификат на каждый 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 и сравнивает с fingerprint, полученным в SDP. Если совпало – эндпоинт говорит с той же стороной, чей отпечаток пришёл по сигналу. Если нет – соединение разрывается.

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

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

Тонкость, которую стоит знать: сертификат самоподписанный и одноразовый. Он не выдан публичным CA, в нём нет 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 и завершать man-in-the-middle, пока сигнальный канал не аутентифицирован. Это атака из §4.2 RFC 8826. Защита – HTTPS для страницы и HTTPS/WSS для сигнального эндпоинта. Без них вся архитектура DTLS-SRTP рушится на сигнальной плоскости: медиа шифруется между атакующим и каждой жертвой, а не между жертвами.

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

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

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

Unknown 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, каждая сторона может доказать другой (и браузеру) идентичность звонящего, заверенную сторонним identity provider (IdP), а не самим сайтом.

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

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

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

Шаблон, который ставится в проде: приложение аутентифицирует пользователя на сигнальном сервере (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 года, более 239 запущенных проектов. Защита медиа-плоскости – рутина: каждый проект ставит DTLS-SRTP по умолчанию, каждый проект терминирует HTTPS на сигнальном шлюзе и каждый проект аудитит конфигурацию SFU на предмет токен-привязанного доступа к комнатам. End-to-end-шифрование – разговор отдельный: большинству продуктов в live-shopping и потребительском сегменте SFrame не нужен; продуктам в телемедицине и регулируемых финансах – часто нужен; e-learning сидит посередине, в зависимости от юрисдикции. Масштабируется шаблон «DTLS-SRTP для транспортной безопасности, JWT-привязанная аутентификация для identity, SFrame поверх, когда модель угроз требует E2EE сквозь SFU».

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

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

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

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

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

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

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

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

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

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

Само шифрование выполняется in-place и не добавляет байт – AES-CM и AES-GCM работают над payload как есть. Итого «зашифровано vs открыто» по проводу – около 9 кбит/с на 1,5-мегабитном звонке, то есть 0,6% битрейта. На CPU современные x86 и ARM имеют инструкции AES (AES-NI на x86, Cryptography Extensions на ARMv8); одно ядро шифрует сотни мегабит в секунду, так что нагрузка на CPU телефона неощутима на фоне декодирования видео. Одноразовый DTLS-хендшейк добавляет один round-trip к setup-у – обычно 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, закрывающий пробел SFU.

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

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

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

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