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-шифрование отпечатков для 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; если же допустить ошибку – «зашифрованный» пайплайн всё равно может утекать через метаданные, принимать поддельные сегменты или позволять любому арендатору импортировать поток в ваш ingest. Эта статья объясняет, за что отвечает каждый протокол, где происходит handshake в live- и VOD-пайплайнах, а также описывает три ошибки конфигурации, из-за которых чаще всего происходят инциденты в продакшене в 2026 году.

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

Каждый современный стриминг-продукт должен по умолчанию использовать шифрование. App Store отклоняет WebRTC-приложения, передающие RTP в открытом виде. Браузеры отказываются воспроизводить HLS по URL с http://. Корпоративные клиенты не проходят security review, если первым же обнаруженным нарушением оказывается самоподписанный сертификат. Продакт-менеджер, который не различает TLS, DTLS, SRTP и mTLS, либо механически копирует обещание вендора «банковский уровень шифрования», не понимая, что именно защищено – медиапоток или манифест, – либо тратит весь спринт на устранение проблемы SOC 2, которую младший инженер мог бы закрыть за день. Эта статья объясняет четыре протокола простым языком, показывает, какой из них защищает ту или иную часть конвейера, и перечисляет практические дефолты на 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-пакетов после завершения handshake в DTLS. Описан в RFC 3711 (март 2004). DTLS выполняет handshake, а SRTP обеспечивает шифрование каждого пакета.

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

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

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

Две особенности TLS 1.3, важные именно для стриминга. 0-RTT (zero round-trip time) resumption позволяет возвращающемуся клиенту отправить первый HTTP-запрос одновременно с handshake, экономя один round trip при повторных подключениях – это полезно, например, когда зритель переподключается к прямой трансляции после кратковременного разрыва. Минус – небольшое окно для 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, где сообщения рукопожатия могут приходить в неправильном порядке, дублироваться или вовсе не доставляться. DTLS сохраняет модель безопасности TLS и добавляет механизмы, позволяющие функционировать на ненадёжном канале передачи датаграмм: каждое сообщение рукопожатия содержит порядковый номер, чтобы получатель мог восстановить правильный порядок; каждый фрагмент имеет явную длину, чтобы корректно собирать пакеты, разбитые на несколько датаграмм; обмен безсостоятельными куками на первом этапе предотвращает атаку, при которой злоумышленник с поддельным исходным адресом заставляет сервер выполнять ресурсоёмкую работу по установке соединения.

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

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

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

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

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

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

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

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

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

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

В обычном TLS только сервер предъявляет сертификат. Клиент проверяет его подлинность, но сервер не имеет криптографического подтверждения личности клиента и полагается на данные, предоставляемые приложением – например, имя пользователя, 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). На уровне протокола его использование обходится в один дополнительный сертификат в процессе рукопожатия и несколько сотен байт трафика. На операционном уровне стоимость выше: требуется управлять жизненным циклом сертификатов – каждому клиенту, взаимодействующему с сервером, нужен сертификат от доверенного сервером центра сертификации, который необходимо регулярно обновлять до истечения срока действия.

В стриминге 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 года для этого обычно использовали общий секрет в заголовке 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, выполняет handshake DTLS 1.3 по выбранному ICE-пути, и с этого момента каждый RTP-пакет шифруется с помощью SRTP с алгоритмом AES-128-GCM.

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

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

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

Ошибка 1: считать «у нас HTTPS» доказательством end-to-end шифрования. Классическая ошибка при enterprise security review. HTTPS на стороне клиента не гарантирует, что данные были зашифрованы на стороне приёма, что соединение CDN с 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-рукопожатие, и пусть механизм exporter из RFC 5764 §4.2 выполняет деривацию мастер-ключа SRTP.

Ошибка 4: выкатить mTLS без runbook'а для ротации сертификатов. Клиентский сертификат, истекающий в 03:00 в субботу, – это прод-инцидент, который ждёт своего часа. Используйте короткоживущие сертификаты (не более 24 часов для service-to-service, до 90 дней для ingest-энкодеров) и автоматизированный пайплайн продления. 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 году, оставляет процессор и пропускную способность неиспользованными.

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

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

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

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

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

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