DTLS en VoIP: cómo DTLS y DTLS-SRTP protegen las claves de medios en WebRTC y SIP

Toda llamada de voz cifrada enfrenta el dilema del huevo y la gallina: el audio está protegido por SRTP, pero SRTP necesita una clave secreta, y esa clave tiene que llegar a ambos extremos sin que nadie la intercepte antes. La forma en que las dos partes acuerdan esa clave es la decisión más importante de la seguridad de medios en tiempo real, y es justamente ahí donde DTLS se gana su lugar en la pila de protocolos.

DTLS (Datagram Transport Layer Security) lleva la confidencialidad y la autenticación de TLS a transportes no confiables y tolerantes a la pérdida de paquetes, como UDP, que es justamente el transporte que usan la voz y el video en tiempo real. Combinado con SRTP, se convierte en DTLS-SRTP: el mecanismo de intercambio de claves que WebRTC hace obligatorio y que aparece cada vez más en la frontera entre los medios de navegador y las redes SIP tradicionales. Esta guía explica qué es DTLS, cómo funciona el handshake DTLS sobre UDP, cómo DTLS-SRTP negocia las claves de medios, en qué se diferencia DTLS de TLS y qué papel cumple un controlador de borde de sesión (SBC) en medio de todo esto.

¿Qué es DTLS?

DTLS es TLS rediseñado para transportes que no garantizan ni la entrega ni el orden. El TLS estándar supone un flujo de bytes confiable y ordenado, que es lo que proporciona TCP. Los medios en tiempo real no funcionan sobre TCP, porque un paquete de voz retransmitido que llega tarde es peor que inútil: el instante que representa ya pasó. La voz y el video viajan sobre UDP, donde los paquetes pueden perderse, duplicarse o llegar desordenados, y TLS, tal como está definido, no puede manejar eso.

DTLS resuelve el problema conservando intacto el modelo de seguridad de TLS y añadiendo los mecanismos que le faltan a UDP. Introduce números de secuencia explícitos para que el receptor detecte huecos y desorden, un temporizador de retransmisión para que un mensaje de handshake perdido se reenvíe en lugar de bloquear la conexión, y una regla según la cual cada mensaje de handshake debe caber dentro de los límites del transporte. La criptografía, los conjuntos de cifrado y el modelo de confianza son los mismos que usa TLS. Lo que cambia es todo lo que los envuelve.

El protocolo ha evolucionado a la par de TLS. DTLS 1.2 (RFC 6347) corresponde a TLS 1.2, y DTLS 1.3 (RFC 9147) corresponde a TLS 1.3, del que hereda un handshake más rápido y conjuntos de cifrado modernos. En VoIP, DTLS importa por una razón principal: es el mecanismo que usa WebRTC para establecer las claves que protegen los medios.

Cómo funciona el handshake DTLS

El handshake DTLS sigue la misma lógica que un handshake TLS, con adaptaciones que le permiten completarse de forma confiable sobre un canal de datagramas con pérdidas. El objetivo no cambia: dos extremos se autentican mutuamente y acuerdan un secreto compartido antes de que circule cualquier medio protegido.

El flujo del handshake

1. ClientHello y HelloVerifyRequestEl cliente abre con un ClientHello. El servidor responde con un HelloVerifyRequest que lleva una cookie sin estado, y el cliente reenvía su ClientHello devolviendo esa cookie. Este viaje de ida y vuelta existe para frenar la amplificación de ataques de denegación de servicio: el servidor no reserva ningún estado hasta tener la prueba de que el cliente puede recibir tráfico en la dirección que declara.
2. Parámetros y certificado del servidorEl servidor envía su ServerHello con el conjunto de cifrado elegido, seguido de su certificado y sus parámetros de intercambio de claves. En DTLS-SRTP el certificado suele ser autofirmado, porque la confianza proviene de una huella digital que viaja en la señalización y no de una CA pública.
3. Intercambio de claves y certificado del clienteEl cliente envía su propia contribución al intercambio de claves y, cuando hay autenticación mutua, su propio certificado. En ese momento ambos lados ya tienen el material necesario para derivar un secreto maestro compartido.
4. ChangeCipherSpec y FinishedCada lado indica que pasará a usar las claves negociadas y luego envía un mensaje Finished que incluye un hash de todo el handshake. Si alguno de los dos Finished no se verifica, el handshake se interrumpe.

Durante todo el proceso, cada grupo de mensajes está protegido por un temporizador de retransmisión. Si la respuesta esperada no llega, el emisor vuelve a enviar los mensajes en lugar de dar por hecho que hubo una falla, y eso es lo que permite completar el handshake sobre una ruta que descarta paquetes sin avisar.

Por qué importa el intercambio de cookies

La cookie del HelloVerifyRequest es un detalle pequeño con un papel de seguridad desproporcionado. Como DTLS funciona sobre UDP, un atacante puede falsificar sin esfuerzo la dirección de origen de un ClientHello y dirigir la costosa respuesta criptográfica del servidor hacia una víctima. Exigir que el cliente devuelva una cookie emitida por el servidor lo obliga a demostrar que realmente puede recibir tráfico en la dirección que declara, lo que cierra ese vector de amplificación antes de que empiece cualquier trabajo real.

Cómo DTLS-SRTP negocia las claves de medios

DTLS-SRTP no es una forma de cifrar los medios. Los medios siguen viajando por SRTP, exactamente igual que con cualquier otro método de intercambio de claves. Lo que hace DTLS-SRTP es resolver el problema más difícil: hacer llegar las claves SRTP a ambos extremos de forma segura. Para ello ejecuta un handshake DTLS completo directamente sobre la ruta de medios y luego deriva las claves SRTP del secreto que produce ese handshake.

Lo ingenioso está en cómo se ancla la confianza. Los dos extremos intercambian certificados autofirmados durante el handshake DTLS, pero un certificado autofirmado no prueba nada por sí solo. El vínculo lo aporta la señalización: cada extremo publica un hash de su certificado como atributo a=fingerprint en el SDP de la oferta y la respuesta, ya sea SIP o WebRTC. Cuando el handshake DTLS termina, cada lado compara el certificado que realmente recibió con la huella que se le prometió en la señalización. Si coinciden, queda confirmado que el handshake se hizo con el interlocutor previsto y no con un intruso.

Este diseño le da a DTLS-SRTP una propiedad que SDES no tiene. Con SDES, la clave maestra SRTP real va en el cuerpo SDP, de modo que cualquiera que pueda leer la señalización puede descifrar los medios; por eso SDES solo es seguro cuando la propia señalización SIP va protegida con TLS. Con DTLS-SRTP, la señalización solo transporta una huella digital, que no le sirve de nada a un atacante: el material de claves real nunca sale de la ruta de medios y se negocia de nuevo en cada sesión. Esa separación es la razón por la que WebRTC exige DTLS-SRTP y prohíbe SDES por completo.

De dónde salen las claves

Cuando termina el handshake DTLS, ambos extremos aplican la misma función de derivación de claves, definida en el RFC 5764, sobre el secreto maestro compartido para obtener las claves maestras y las sales de SRTP. La asociación DTLS puede seguir activa solo como contexto de claves, mientras SRTP se encarga de transportar el audio y el video propiamente dichos. Ningún lado transmitió jamás una clave SRTP en claro, y ninguno confió en un mensaje que no pudiera verificar contra la huella digital de la señalización.

DTLS vs. TLS: ¿cuál es la diferencia?

DTLS y TLS comparten el mismo núcleo criptográfico, los mismos conjuntos de cifrado y el mismo modelo de confianza. La diferencia está en el transporte para el que se diseñó cada uno y, en las redes de voz, en la función que termina cumpliendo cada uno. TLS funciona sobre TCP, confiable y orientado a conexión, y protege la señalización SIP. DTLS funciona sobre UDP, no confiable y sin conexión, y en su forma DTLS-SRTP protege el intercambio de claves de medios.

Propiedad	TLS	DTLS
Transporte	TCP (confiable, ordenado)	UDP (no confiable, sin orden)
Manejo de la pérdida de paquetes	Depende de TCP	Retransmisión integrada
Función típica en VoIP	Cifrado de la señalización SIP (puerto 5061)	Intercambio de claves de medios DTLS-SRTP
Mecanismo anti-DoS	Handshake TCP	Intercambio de cookies sin estado
Sensibilidad a la latencia	Bloqueo de cabeza de línea ante pérdidas	Sin bloqueo de cabeza de línea

En la práctica, los dos protocolos se complementan en lugar de competir. Una llamada segura de WebRTC a SIP suele usar ambos a la vez: TLS protege la señalización SIP del lado de la red, mientras DTLS-SRTP negocia las claves de medios del lado del navegador. Ninguno reemplaza al otro, y a menudo un SBC tiene que hablar los dos protocolos al mismo tiempo, cada uno en un tramo distinto de la misma llamada.

DTLS-SRTP en la frontera entre WebRTC y SIP

DTLS-SRTP es obligatorio en WebRTC y prácticamente universal en las comunicaciones basadas en navegador, pero la mayoría de los operadores SIP y de las PBX heredadas nunca lo adoptaron. Usan SDES sobre TLS, o RTP sin cifrar cuando no se negocia ningún cifrado. Cuando un navegador necesita llegar a un número telefónico a través de la troncal de un operador, algo tiene que situarse entre los dos mundos y traducir el intercambio de claves. Ese algo es un SBC.

Como un controlador de borde de sesión funciona como agente de usuario back-to-back (B2BUA), termina por completo los medios en cada tramo y los vuelve a originar de forma independiente. En el tramo del navegador puede ejecutar el handshake DTLS, verificar la huella digital y derivar las claves SRTP a la manera de WebRTC. En el tramo del operador puede negociar SDES sobre TLS, convertir a RTP sin cifrar o aplicar lo que admita el otro extremo. Los dos tramos tienen contextos criptográficos totalmente separados, así que el navegador obtiene su DTLS-SRTP obligatorio sin que el operador tenga que cambiar nada. Es la misma frontera de cifrado por tramo que se describe en la arquitectura de pasarela de WebRTC a SIP, donde el traspaso del cifrado de medios es uno de los cinco subsistemas de traducción que realiza la pasarela.

La frontera implica más que cifrado. El mismo SBC se ocupa de las demás diferencias entre WebRTC y SIP: la terminación de ICE, para que los candidatos de recorrido de NAT del navegador se resuelvan en una dirección estable; la mediación de códecs, cuando el navegador ofrece Opus y el operador quiere G.711; y la normalización de encabezados SIP, para que la llamada parezca nativa en cada lado. La traducción de DTLS-SRTP es una tarea más entre las que realiza la pasarela, pero es la que mantiene la confidencialidad de los medios de punta a punta.

Preguntas frecuentes

Conclusión

DTLS existe porque los medios en tiempo real no pueden esperar las idas y vueltas de TCP, y porque los medios seguros no pueden depender de claves que viajan en una señalización en claro. Al llevar el modelo de seguridad de TLS a UDP y combinarlo con SRTP, DTLS-SRTP resuelve el intercambio de claves de una manera que sobrevive a la pérdida de paquetes, resiste la suplantación y nunca expone una clave de medios a quien lea la señalización. Esa combinación es la razón por la que se convirtió en la base obligatoria de la seguridad de medios en WebRTC.

La complicación en las redes de producción es que los navegadores hablan DTLS-SRTP y la mayoría de los operadores y de las PBX no. Conectar esos dos mundos sin debilitar ninguno es un problema de cifrado por tramo, y es exactamente el tipo de traducción para el que existe un controlador de borde de sesión en el perímetro de la red.