Una llamada segura tiene más de una ruta de datos. La señalización coordina quién llama y cómo se conectan los extremos; la ruta de medios transporta audio y vídeo. Proteger una ruta no protege automáticamente la otra, y ninguna de ellas por sí sola oculta todos los patrones de comunicación.
WebRTC aporta mecanismos de seguridad importantes, pero las comprobaciones de identidad de la aplicación, las funciones de sus servidores y el modo de grabación siguen determinando el límite completo de privacidad.
La señalización y los medios cumplen funciones distintas
| Capa | Finalidad habitual | Pregunta de seguridad |
|---|---|---|
| Señalización | Invitaciones, descripciones de sesión y candidatos de conexión | ¿Quién puede leer o alterar la información de establecimiento y cómo se autentica al interlocutor previsto? |
| Medios | Audio, vídeo y flujos relacionados en tiempo real | ¿Dónde termina el cifrado y qué extremos pueden acceder a los medios? |
| Registros operativos | Enrutamiento, tiempos de conexión y estado de entrega | ¿Qué metadatos puede observar el servicio o la red? |
| Grabación | Producir una copia que se conservará | ¿Quién recibe texto en claro o claves de grabación utilizables y dónde se almacena la copia? |
Un protocolo de mensajería puede transportar señalización cifrada, pero WebRTC no exige universalmente el formato de encapsulado de un mensajero concreto. Son posibles otros diseños autenticados.
Qué proporciona DTLS-SRTP
La Arquitectura de seguridad de WebRTC, RFC 8827, exige proteger los canales de medios y describe el establecimiento de claves DTLS-SRTP. Simplificando, DTLS ayuda a establecer el contexto criptográfico y SRTP protege los paquetes de medios en tiempo real.
Importan los extremos de esa protección. Una conexión cifrada directa entre participantes es distinta de una conexión que termina en un servidor de procesamiento de medios. Algunos sistemas multiparticipante añaden una capa independiente de extremo a extremo sobre el cifrado de transporte hacia el servidor. La palabra «WebRTC» por sí sola no indica qué arquitectura utiliza un producto.
Por qué importa autenticar la señalización
El establecimiento de una llamada puede contener información utilizada para vincular la conexión de medios con la parte prevista. Si un atacante puede sustituir esa información sin ser detectado, el cifrado puede establecer una conexión protegida con el extremo equivocado.
RFC 8827 analiza esta relación entre señalización, identidades y huellas DTLS. HTTPS protege una conexión con el servicio de señalización; por sí solo no elimina la necesidad de considerar un servicio malicioso o comprometido. La señalización autenticada de extremo a extremo o un mecanismo independiente apropiado para verificar al interlocutor pueden reforzar ese límite.
La confidencialidad de la señalización es un objetivo relacionado pero diferente: limita quién puede leer los detalles del establecimiento. Un diseño debería explicar tanto la confidencialidad como la autenticación, en lugar de tratar un bloque cifrado como prueba suficiente de ambas.
Cifrar la señalización no hace invisible una llamada
El retransmisor puede seguir sabiendo entre qué cuentas o dispositivos enruta. Los observadores de la red pueden ver los tiempos de conexión, el volumen de tráfico y las direcciones de servidores. Los interlocutores o la infraestructura de retransmisión también pueden conocer información de red según el diseño de la conexión.
Por tanto, cifrar una invitación de llamada no demuestra que el servicio no pueda inferir una llamada, mapear relaciones o conservar registros relacionados con ella. Ocultar el contenido y ocultar los patrones de tráfico son problemas distintos.
El límite publicado por Livara
La página de seguridad de Livara describe las llamadas directas y grupales como cifradas de extremo a extremo, pero establece una excepción explícita para la grabación opcional en servidor: mientras el estado visible REC esté activo, la llamada usa cifrado de transporte en lugar de E2EE.
Su modelo de amenazas también rechaza afirmaciones de anonimato de metadatos y protección frente a un dispositivo comprometido. Son declaraciones del producto, no una verificación independiente de todas las rutas de llamada. Esta guía no afirma un límite de participantes, un formato de señalización ni una implementación poscuántica de medios no verificados.
En particular, un intercambio de claves poscuántico del mensajero no actualiza automáticamente un protocolo de negociación separado de medios WebRTC. Los algoritmos y la vinculación de claves en la ruta de medios deben evaluarse de forma independiente.
Antes de una llamada sensible
- Confirme los participantes y revise los cambios de identidad inesperados.
- Compruebe si la grabación está activada y qué dice la aplicación que cambia con ello.
- Comprenda si el servicio procesa los medios o solo reenvía paquetes protegidos.
- Tenga en cuenta los dispositivos y las habitaciones de los participantes: malware, capturas de pantalla o alguien escuchando cerca pueden exponer contenido después de descifrarlo.
- Pida pruebas de arquitectura y ensayos del modo exacto que utiliza, en lugar de confiar en una etiqueta general de «llamadas cifradas».
Una afirmación de seguridad útil identifica por separado quién puede acceder a la señalización, los medios, los metadatos y las grabaciones.
