DTLS, SRTP, TLS, mTLS: слой шифрования для медиа

Опубликовано: 2026-05-20 · Время чтения: 14 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 со стандартами: IETF RFC 8446 (TLS 1.3, август 2018), RFC 9147 (DTLS 1.3, апрель 2022), RFC 5764 (DTLS-SRTP, май 2010), RFC 3711 (SRTP, март 2004), RFC 8827 (WebRTC Security Architecture, январь 2021), RFC 8826 (Security Considerations for WebRTC, январь 2021), RFC 8842 (SDP-fingerprint для DTLS-SRTP, январь 2021), RFC 9849 (TLS Encrypted Client Hello, март 2026), Apple HLS Authoring Specification ревизия 2025-09 и анонс origin-mTLS в AWS CloudFront (февраль 2026).

TL;DR

Стриминговое медиа в 2026 году шифруется четырьмя протоколами, которые на слайде выглядят похоже, но живут в разных частях стека: TLS защищает HTTP-трафик (манифесты HLS, сегменты DASH, сигналинг), DTLS делает то же самое поверх UDP и является handshake'ом, который запускает каждый WebRTC-звонок, SRTP шифрует сами RTP-пакеты с медиа после того, как handshake завершён, а mTLS добавляет вторую сторону с сертификатом, чтобы и клиент, и сервер криптографически доказывали, кто они. Если расставить эти слои правильно – поток устойчив к прослушиванию, подмене и имперсонации end-to-end; если ошибиться – «зашифрованный» pipeline всё равно протекает по метаданным, принимает поддельные сегменты или позволяет любому арендатору импортировать поток в ваш ingest. Эта статья показывает, за что отвечает каждый протокол, где происходит handshake в live- и в VOD-пайплайне, и три ошибки конфигурации, на которых ломается большинство продовых инцидентов в 2026 году.

Зачем это понимать

Каждый современный стриминг-продукт обязан отгружаться зашифрованным по умолчанию. App Store отклоняет WebRTC-приложения, которые шлют RTP в открытом виде. Браузеры отказываются играть HLS по URL с http://. Корпоративные клиенты не проходят security review, если первая же находка – самоподписанный сертификат. Продакт-менеджер, который не различает TLS, DTLS, SRTP и mTLS, либо штампует обещание вендора «банковский уровень шифрования», не понимая, что именно покрыто – медиа-путь или путь манифеста, – либо сжигает спринт на находку SOC 2, которую junior-инженер закрыл бы за день. Эта статья объясняет четыре протокола простым языком, показывает, какой из них защищает какую часть pipeline'а, и перечисляет практические дефолты на 2026 год.

Одно предложение про каждый протокол, прежде чем углубляться

До разбора – четыре названия по одному предложению.

TLS – Transport Layer Security, шифрование, которое оборачивает HTTPS, работает поверх TCP и защищает каждый запрос манифеста HLS, каждую загрузку DASH-сегмента, каждое сигнальное сообщение и каждый вход в дашборд. Актуальная версия: TLS 1.3 (RFC 8446, август 2018). Стандарт, который вы и так знаете.

DTLS – Datagram Transport Layer Security, те же гарантии безопасности, что у TLS, но адаптированные под работу поверх UDP, где пакеты могут приходить не по порядку, дублироваться или теряться. Актуальная версия: DTLS 1.3 (RFC 9147, апрель 2022). В WebRTC – это протокол, который выполняет первичный handshake, прежде чем потечёт медиа.

SRTP – Secure Real-time Transport Protocol, шифрование отдельных RTP-пакетов после того, как DTLS закончил handshake. Описан в RFC 3711 (март 2004). DTLS делает handshake; SRTP делает работу по каждому пакету.

mTLS – mutual TLS, режим TLS, в котором обе стороны предъявляют сертификат и проверяют чужой, а не только клиент проверяет сервер. Не отдельный протокол – режим деплоя. Используется в аутентификации service-to-service, в ingest, и с февраля 2026 года – в origin-mTLS у CloudFront для end-to-end zero-trust доставки.

TLS – слой, который уже защищает большую часть pipeline'а

TLS сидит между TCP и HTTP. Каждый запрос HLS-манифеста, каждая загрузка DASH-сегмента у CDN, каждый запрос вашей команды эксплуатации в дашборд – всё это идёт поверх TLS в 2026 году. Apple HLS Authoring Specification (ревизия 2025-09, §2.1) требует HTTPS для любого HLS-контента, доставляемого в App Store-приложение; DASH-IF рекомендует то же; современные браузеры выбрасывают ошибку mixed content на сегменты по http://, которые ссылаются со страницы по https://.

Механика в одном абзаце. Клиент открывает TCP-соединение к серверу. Стороны выполняют TLS-handshake: клиент шлёт ClientHello со списком шифронаборов и версий TLS, которые поддерживает, плюс случайное число; сервер отвечает ServerHello, выбирая один шифронабор, TLS-сертификат, подписанный доверенным CA, и собственное случайное число; клиент валидирует сертификат, выводит общий ключевой материал через Диффи-Хеллмана на эллиптической кривой (X25519 – современный дефолт), и обе стороны переходят на шифрованный обмен. TLS 1.3 завершает это за один сетевой круг (round trip), вдвое меньше, чем требовал TLS 1.2. Как только handshake закончен, каждый HTTP-запрос и ответ заворачиваются в Application Data-запись, которую никто на пути не может прочитать или подменить.

Две фичи TLS 1.3, важные именно для стриминга. 0-RTT (zero round-trip-time) resumption позволяет возвращающемуся клиенту отправить первый HTTP-запрос вместе с handshake, экономя round trip на повторных визитах – полезно для зрителя, который переподключается к live-трансляции после короткого разрыва. Цена – небольшое окно для replay-атаки, поэтому большинство HLS / DASH-деплоев включают 0-RTT только на идемпотентных GET-запросах за сегментами, никогда – на POST в сигналинг. Encrypted Client Hello (ECH), получивший статус RFC 9849 в марте 2026 года, шифрует поле Server Name Indication (SNI), чтобы наблюдатель на пути не мог определить, к какому хосту клиент обращается. Cloudflare, iOS, Android, Edge и Firefox уже отгрузили ECH; для стриминг-продуктов, работающих в ограничивающих сетях (корпоративные прокси, некоторые национальные сети), ECH – это разница между потоком, который загружается, и потоком, который блокируется фильтром по имени хоста.

На практике TLS для стриминг-продукта в 2026 году – это три вещи: отдавать каждый URL по HTTPS (без plaintext-фолбэков), выбирать TLS 1.3 с TLS 1.2 только как фолбэк для длинного хвоста старых устройств, и использовать HSTS (HTTP Strict Transport Security) с max-age=31536000, чтобы ни один клиент никогда не откатился на открытый HTTP.

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

DTLS – это TLS, который выживает при потерях

DTLS существует потому, что TLS полагается на надёжный, упорядоченный транспорт (TCP) и разваливается на UDP, где сообщения handshake'а могут прийти не по порядку, дублироваться или вообще не дойти. DTLS сохраняет модель безопасности TLS и добавляет механику для выживания на ненадёжном datagram-канале: каждое сообщение handshake несёт sequence number, чтобы получатель мог переупорядочить; каждый фрагмент несёт явную длину, чтобы пакет, разбитый на две datagram'ы, собирался корректно; stateless cookie exchange в первом раунде предотвращает атаку, при которой злоумышленник с поддельным source-адресом заставляет сервер выполнять дорогую handshake-работу.

DTLS 1.3 (RFC 9147, апрель 2022) подтянул DTLS до уровня TLS 1.3. Тот же handshake за один round trip. Тот же обмен ключами на эллиптической кривой. Та же forward secrecy. Экосистема WebRTC мигрирует с DTLS 1.2 на DTLS 1.3 в течение 2025 и в 2026 году; основные браузеры с середины 2025 года напрямую отклоняют DTLS 1.0 и 1.1, и media-сервер, предлагающий только устаревшие версии, не сможет договориться с текущим Chrome или Safari.

В WebRTC DTLS выполняет две работы, которые часто путают. Первая – сам handshake: два peer'а обмениваются сертификатами по ICE-выбранному пути, доказывают владение приватным ключом и выводят общий ключевой материал. Сертификат почти всегда самоподписанный – свежая пара ECDSA P-256, сгенерированная браузером для каждой сессии, – потому что идентичность сертификата привязана к сигнальному каналу через fingerprint сертификата в строке a=fingerprint: SDP (RFC 8842, январь 2021). Сигнальный сервер ручается, что SDP пришёл от правильного пользователя; SDP ручается, что DTLS-сертификат принадлежит этому пользователю; DTLS handshake верифицирует сертификат против fingerprint'а. Никакой публичный CA не задействован.

Вторая работа – наработка ключей для SRTP. Exporter DTLS handshake'а – функция деривации ключа, описанная в RFC 5705, – производит master key, который SRTP использует для шифрования каждого следующего RTP-пакета. Этот совместный режим называется DTLS-SRTP и описан в RFC 5764 (май 2010); RFC 8827 (WebRTC Security Architecture, январь 2021) делает DTLS-SRTP обязательным для каждого WebRTC-медиапотока. Никакого легитимного WebRTC-деплоя в 2026 году, который не использует DTLS-SRTP, не существует; media-сервер, принимающий RTP в открытом виде, – это ошибка конфигурации, а не фича.

SRTP – само пакетное шифрование

DTLS делает handshake; SRTP делает работу. Как только handshake завершён и у обеих сторон есть SRTP master key, каждый RTP-пакет – аудиокадр, видеокадр, FEC-пакет – заворачивается SRTP перед уходом в сеть.

Механика коротко. SRTP берёт master key и прогоняет его через функцию деривации ключа – AES в счётчиковом режиме, ведомом индексом RTP-пакета, – производя свежий session key для шифрования, session key для аутентификации и session salt. Полезная нагрузка RTP шифруется AES-CTR (или AES-GCM в современных деплоях), затем добавляется 10-байтный тег HMAC-SHA1 (или встроенный AEAD-тег для GCM). Заголовок RTP остаётся открытым, чтобы промежуточные узлы могли маршрутизировать пакет, но он покрыт тегом аутентификации – любая байтовая подмена выявляется получателем как ошибка верификации, и пакет отбрасывается.

Сопутствующий протокол SRTCP защищает RTCP, контрольный канал с receiver report'ами, sender report'ами и feedback-сообщениями для управления перегрузкой. RFC 3711 §3.4 делает целостность SRTCP обязательной – подменённый RTCP-отчёт может заставить отправителя обвалить собственную bitrate ladder, а стоимость вычисления тега пренебрежимо мала по сравнению с потерями от деградировавшего звонка.

Две продовые реальности SRTP. Во-первых, накладные расходы на пакет небольшие – 4 байта SRTP-индекса плюс 10-байтный (HMAC-SHA1) или 16-байтный (GCM) тег аутентификации на пакет, – но они суммируются: видеопоток на 2 Mbps с пакетами по 1200 байт даёт около 208 пакетов в секунду, так что только аутентификация SRTP добавляет ~16 kbps. На стеснённом мобильном линке это разница между чистым потоком и буксующим. Во-вторых, выбор шифра важен. AES-128-CM с HMAC-SHA1 был дефолтом оригинального RFC 3711. AES-128-GCM и AES-256-GCM, описанные в RFC 7714 (декабрь 2015), – современные дефолты: чуть больше тег, но гораздо быстрее на железе с инструкциями AES-NI (каждый серверный CPU с 2010 года, каждая современная мобильная SoC). Media-сервер, всё ещё дефолтящий в AES-CM с HMAC-SHA1 в 2026 году, оставляет CPU и полосу на столе.

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

mTLS – когда «сервер тот, за кого себя выдаёт» недостаточно

В обычном TLS только сервер предъявляет сертификат. Клиент проверяет идентичность сервера; у сервера нет криптографического доказательства, кто клиент, и он опирается на то, что предложит приложение, – username, bearer-токен, API-ключ. Mutual TLS (сокращённо mTLS) переворачивает это: клиент тоже предъявляет сертификат, сервер валидирует его против доверенного CA, и соединение продолжается только если оба сертификата проходят.

mTLS – не отдельный RFC. Это режим TLS, доступный с TLS 1.0 (RFC 2246, 1999), формализованный в TLS 1.3 через расширение certificate_request в RFC 8446 §4.3.2. Цена на уровне протокола – один лишний сертификат в handshake, несколько сотен байт. Цена на операционном уровне – жизненный цикл сертификата: каждому клиенту, говорящему с сервером, нужен сертификат от CA, которому сервер доверяет, и этот сертификат должен ротироваться до истечения.

В стриминге mTLS встречается в трёх местах.

Аутентификация ingest'а. Live-энкодер, заливающий поток на origin, может аутентифицироваться mTLS вместо (или в дополнение к) stream key в URL. SRT over TLS, RIST с TLS-профилем и RTMPS – все поддерживают деплой mTLS. Плюс: stream key в URL утекает, если кто-то записывает HTTP-логи энкодера; клиентский сертификат в hardware security module энкодера не извлекается без контроля над энкодером. Минус: ротировать сертификаты по флоту ingest-энкодеров операционно нетривиально.

Защита origin'а между CDN и origin. До 2026 года это обычно делали shared secret'ом в заголовке X-Origin-Token. В феврале 2026 года AWS CloudFront запустил origin mTLS, в котором CloudFront предъявляет клиентский сертификат при запросе к origin, а origin валидирует его до выдачи ответа. У Fastly, Akamai и Cloudflare есть эквиваленты. Результат – end-to-end взаимно аутентифицированный TLS: зритель ↔ CDN (TLS), CDN ↔ origin (mTLS), без точки в цепочке, работающей на неявном доверии.

Service-to-service внутри control plane стриминга. Сигнальный сервер → транскодер, packager → origin, сборщик аналитики → дашборд – каждый внутренний вызов в укреплённом стриминг-продукте идёт по mTLS, часто через service mesh (Istio, Linkerd), который автоматически выписывает короткоживущие (24-часовые) сертификаты. Зритель этот слой никогда не видит, но любой security review для энтерпрайз-клиента про него обязательно спросит.

mTLS не шифрует медиа на проводе сильнее, чем обычный TLS, – оба используют один и тот же шифронабор после handshake'а. Что mTLS добавляет – идентичность: гарантию, что соединение идёт между ровно теми двумя сторонами, которых вы ожидаете, а не между вами и имперсонатором, угадавшим stream key.

Разбор на примере – где каждый протокол появляется в одной live-трансляции

Стримится живой концерт. Камера кормит OBS-энкодер; OBS пушит по SRT-over-TLS на ingest-origin; ingest-origin транскодирует и пакует в HLS; CDN раздаёт; зрители смотрят в iOS Safari и в десктопном браузере.

Шаг 1, энкодер → ingest-origin: SRT-over-TLS с mTLS для аутентификации. Энкодер предъявляет клиентский сертификат, выписанный при настройке площадки; origin валидирует его против CA, привязанного к площадке. Поток нельзя угнать без приватного ключа. Это TLS-с-клиентской-аутентификацией.

Шаг 2, ingest-origin → packager: TLS внутри продакшен-VPC. Packager работает в той же приватной сети; линк идёт по mTLS через service mesh.

Шаг 3, packager → CDN-origin: TLS. Edge-узлы CDN тянут HLS-сегменты и манифесты по HTTPS с origin'а, прикрытого packager'ом; если CDN это поддерживает, эта нога тоже использует mTLS для защиты origin'а. У CloudFront origin-mTLS – GA с февраля 2026 года.

Шаг 4, CDN → зритель: TLS. iOS Safari и десктопный браузер тянут .m3u8 и .ts (или .mp4 для CMAF) по HTTPS. TLS 1.3 с обменом ключами X25519 и шифронабором AES-128-GCM. Encrypted Client Hello прячет имя хоста от наблюдателей на пути.

Шаг 5, если тот же продукт предлагает WebRTC для low-latency-тира: браузер зрителя выбирает ICE-кандидатов с SFU, выполняет DTLS 1.3 handshake по выбранному пути ICE, и с этого момента каждый RTP-пакет шифруется SRTP с AES-128-GCM.

Пять протоколов (считая DTLS+SRTP за два) покрывают пять ног pipeline'а. Каждый байт медиа зашифрован в транзите; на каждой ноге у обеих сторон есть взаимно аутентифицированная идентичность.

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

Частые ошибки

Ошибка 1: считать «у нас HTTPS» доказательством end-to-end шифрования. Классическая ошибка на энтерпрайзном security review. HTTPS на ноге к зрителю не гарантирует, что сегменты были зашифрованы на ingest-ноге, что CDN-to-origin хоп взаимно аутентифицирован и что WebRTC-медиапуть действительно использует SRTP. Каждая нога требует отдельного аудита.

Ошибка 2: всё ещё договариваться о DTLS 1.0 или 1.2 на современном media-сервере. Старые конфиги coturn или Janus иногда оставляют DTLS 1.0 включённым «для совместимости». Современные браузеры его отклоняют; звонок не соединяется, в логах только «DTLS handshake failed». Зафиксируйте конфигурацию: минимум DTLS 1.2, предпочтительно DTLS 1.3. RFC 8996 (март 2021) формально вывел TLS 1.0 и 1.1 из обращения.

Ошибка 3: забыть, что ключевой материал DTLS-SRTP привязан к звонку. Частый баг в WebRTC-стеках – переиспользовать DTLS-сертификат между сессиями, но считать, что ключ SRTP ротируется автоматически. Ключи выводятся из handshake'а; переиспользуете handshake – переиспользуете ключи. Всегда генерируйте свежий DTLS handshake на каждую сессию, и пусть exporter из RFC 5764 §4.2 делает деривацию master key SRTP.

Ошибка 4: выкатить mTLS без runbook'а для ротации сертификатов. Клиентский сертификат, истекающий в 03:00 в субботу, – это прод-инцидент, ждущий своего часа. Используйте короткоживущие сертификаты (24 часа или меньше для service-to-service, 90 дней для ingest-энкодеров) и автоматизированный pipeline продления. SPIFFE / SPIRE, cert-manager в Kubernetes и HashiCorp Vault PKI – три продакшен-уровневых варианта в 2026 году.

Ошибка 5: полагаться на AES-CM с HMAC-SHA1 в SRTP на современном железе. У каждого CPU с 2010 года есть AES-NI; у каждой современной мобильной SoC – аппаратное AES. AES-GCM (RFC 7714) считается быстрее, имеет встроенную аутентификацию и именно его браузеры реально согласуют первым. Media-сервер, дефолтящий в AES-CM в 2026 году, оставляет CPU и полосу неиспользованными.

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

Фора Софт с 2005 года делает WebRTC, видеоконференции, OTT, телемедицину, e-learning, видеонаблюдение и AR/VR – более 239 отгруженных проектов. Слой шифрования – это часть стриминг-продукта, которую клиенты в регулируемых вертикалях (HIPAA в телемедицине, цепочка хранения улик в видеонаблюдении, защита данных учеников в e-learning) изучают первой во время закупки. Мы поставляем продукты с DTLS 1.3, согласованным end-to-end, AES-GCM SRTP, mTLS на каждой ноге ingest'а и origin'а и короткоживущей ротацией сертификатов через service mesh или PKI-pipeline, с дашбордами на ошибки handshake'а, чтобы неправильный шифронабор всплывал за минуты, а не на следующем квартальном аудите.

Ключевые тезисы

• TLS защищает каждую HTTPS-ногу; DTLS делает то же поверх UDP и запускает каждый WebRTC-звонок.
• SRTP шифрует сами RTP-пакеты; DTLS делает handshake, производящий ключ SRTP.
• mTLS добавляет клиентский сертификат, чтобы обе стороны криптографически доказывали идентичность.
• Pipeline 2026 года работает на TLS 1.3, DTLS 1.3, SRTP с AES-GCM и mTLS между всеми внутренними хопами.
• Encrypted Client Hello (RFC 9849, март 2026) прячет имя хоста – важно для ограничивающих сетей.
• Подводные камни операционные, а не криптографические: ротация, версии, аудит по каждой ноге.

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

• NAT, файрволы, STUN, TURN, ICE: как WebRTC реально добирается до телефона – слой обнаружения пути, который работает до DTLS handshake'а.
• TCP и UDP в стриминге – почему DTLS существует рядом с TLS.
• QUIC: новый транспортный уровень – где TLS 1.3 живёт внутри QUIC для HTTP/3-стриминга.