¿Es seguro WebRTC? Cómo protege tu contenido la presentación peer-to-peer

«¿Es seguro WebRTC?» es una de esas preguntas que parecen sencillas y merecen una respuesta en condiciones, sobre todo si estás a punto de hacer una presentación ante el consejo, una llamada con inversores o una propuesta a un cliente a través de esta tecnología. La versión corta es que sí, por diseño, pero la versión honesta explica por qué, porque «es un estándar web» no es, por sí solo, un argumento.

WebRTC es la tecnología que hay detrás de la mayoría de las herramientas modernas de vídeo y control peer-to-peer, incluida la conexión entre el teléfono de un presentador y el ordenador que ejecuta sus diapositivas en Cliqer. Entender qué protege y qué no te permitirá juzgar mejor cualquier herramienta que la utilice, no solo la nuestra.

Qué es realmente WebRTC

WebRTC (Web Real-Time Communication) es un estándar abierto mantenido por el W3C y compatible de forma nativa con todos los navegadores principales. Define cómo dos dispositivos pueden establecer una conexión directa para intercambiar audio, vídeo o datos arbitrarios, sin que ninguna de las partes tenga que instalar un plugin. Puedes consultar la especificación técnica y el contexto en webrtc.org.

La palabra clave es «directa». A diferencia de una videollamada que pasa íntegramente por los servidores de una empresa, WebRTC está diseñado para conectar dos dispositivos entre sí de la forma más directa que permita la red, y solo recurre a un relé cuando no es posible una ruta directa. Esa única decisión de diseño es la razón por la que importa el resto de este artículo: un protocolo construido en torno a conexiones directas necesita un modelo de seguridad distinto al de uno construido en torno a un servidor central, y conviene entender ambas mitades antes de confiarle el contenido de una sala de juntas.

El cifrado no es opcional en WebRTC

Esta es la parte que realmente responde a la pregunta de seguridad. WebRTC no ofrece ningún modo sin cifrar. Toda conexión WebRTC, ya transporte un canal de datos, audio o vídeo, está cifrada por diseño:

• DTLS (Datagram Transport Layer Security) protege los canales de datos, el conducto de baja latencia que se usa para cosas como los comandos de avance de diapositivas y las posiciones del puntero.
• SRTP (Secure Real-time Transport Protocol) protege cualquier medio de audio o vídeo, como una pantalla compartida o la señal de una cámara.
• El intercambio inicial que establece la conexión, llamado señalización, se ejecuta por separado sobre WSS (WebSocket Secure), de modo que el paso de coordinación también está cifrado, incluso antes de que exista el enlace peer-to-peer.

No existe ninguna opción de configuración para desactivarlo. Está integrado en el estándar, lo que supone una garantía sustancialmente distinta de «decidimos activar el cifrado», porque no se puede configurar mal sin que nadie se dé cuenta.

Peer-to-peer frente a enrutamiento por servidor: por qué importa para el contenido

Como WebRTC conecta los dispositivos directamente, una aplicación construida sobre él tiene una opción real que las herramientas enrutadas por servidor no tienen: decidir si el contenido necesita pasar alguna vez por un servidor. En Cliqer, los comandos de avance de diapositivas, las coordenadas del puntero láser, el estado del temporizador y cualquier transmisión de pantalla o cámara viajan directamente entre el dispositivo del presentador y el ordenador anfitrión, o a través de un relé cifrado si no hay una ruta directa disponible. Los servidores de la aplicación coordinan quién está en la sala; nunca están en la ruta de los medios, y tu contenido de presentación nunca se sube.

Esa arquitectura es especialmente importante para cualquier cosa sensible: presentaciones para el consejo, hojas de ruta de producto, datos financieros sin publicar. Profundizamos en ese caso concreto en presentar contenido confidencial.

Dónde encaja el relé

No todas las redes permiten una conexión directa. Los cortafuegos corporativos, el Wi-Fi de los hoteles y el NAT de nivel operador (CGNAT) pueden bloquear la ruta directa que prefiere WebRTC. Cuando eso ocurre, la conexión recurre a un relé TURN, que reenvía los mismos paquetes cifrados con DTLS y SRTP sin tener las claves para descifrarlos. El relé mueve bytes; no puede leerlos.

Explicamos exactamente cómo funciona esa alternativa, y por qué no supone una rebaja de la seguridad, en los servidores TURN, explicados. También es la razón por la que los cortafuegos corporativos rara vez bloquean por completo una herramienta WebRTC bien construida, un tema que tratamos en por qué los cortafuegos corporativos bloquean las herramientas de presentación.

Contra qué no protege WebRTC

El cifrado en tránsito no lo es todo en seguridad, y conviene ser honestos sobre lo que no cubre:

Cómo comprobarlo tú mismo

No tienes por qué fiarte de la palabra de un proveedor en nada de esto. Algunas comprobaciones prácticas:

1. Pide un diagrama de flujo de datos, no una página de marketing, y confirma qué flujos son peer-to-peer y cuáles pasan por servidor.
2. Comprueba si la aplicación requiere reglas de cortafuegos de entrada. Una aplicación WebRTC bien construida solo debería necesitar conexiones salientes.
3. Pregunta qué ocurre en una red que bloquea las conexiones directas. Debería haber un relé cifrado como alternativa, no un fallo total.
4. Lee la documentación de Seguridad y redes para conocer los puertos y protocolos concretos que se utilizan.

Si estás evaluando una herramienta para todo un equipo y no para una sola llamada, incorpora esto a la lista de comprobación de seguridad para software de presentaciones, más amplia, ya que el cifrado es solo un punto entre varios que debería cubrir una revisión en condiciones.

Preguntas frecuentes

Empieza ya

Si el cifrado y el enrutamiento peer-to-peer influyen en cómo evalúas las herramientas de presentación, lee la descripción general de seguridad completa, o prueba Cliqer gratis e inspecciona tú mismo el comportamiento de la conexión antes de presentar nada sensible con él.