Fugas de WebRTC: por qué puede verse tu dirección real incluso detrás de un proxy
WebRTC existe para que los navegadores puedan comunicarse directamente entre sí en llamadas y al compartir pantalla. Para ello necesitan descubrir las direcciones en las que se les puede localizar, y ese proceso de descubrimiento es lo que se denomina una «fuga de WebRTC».
Los candidatos ICE en un párrafo
Cuando una página crea una RTCPeerConnection e inicia una oferta, el navegador reúne candidatos: formas en que otro par podría alcanzarlo. Un candidato host es la dirección de una interfaz local. Un candidato server-reflexive (srflx) es la dirección pública desde la que un servidor STUN vio llegar la petición. Un candidato relay es la dirección de un servidor TURN. Cada candidato se entrega a la página en una línea de texto que contiene la dirección, y así es como un script puede leerla sin que se llegue a hacer ninguna llamada.
Dónde está la fuga
El candidato srflx es el que importa. Para obtenerlo, el navegador envía un pequeño paquete UDP a un servidor STUN, que responde con la dirección que vio. Si tu tráfico HTTP pasa por un proxy pero tu tráfico UDP no, el servidor STUN ve tu conexión real, y la página pasa a tener una dirección que no coincide con la que vio el servidor web. Esa discrepancia es la fuga clásica. Una página de diagnóstico puede mostrarla comparando ambas.
Fíjate en lo que ocurre y en lo que no. No se captura ningún contenido multimedia. No interviene ningún permiso de micrófono ni de cámara. El paquete va al servidor STUN que haya indicado la página, de modo que ese servidor, como cualquier servidor con el que contactas, ve tu dirección.
Qué han cambiado los navegadores
Los candidatos host solían exponer direcciones privadas de la red local, como 192.168.1.23, útiles para identificar mediante huella digital una red doméstica. Los navegadores modernos las sustituyen por nombres mDNS generados al azar que terminan en .local, de modo que la página ve un nombre opaco y no una dirección. Un diagnóstico que informa de «enmascarado por el navegador» se refiere a ellos. Firefox y Brave también ofrecen ajustes que impiden recopilar candidatos fuera del proxy, y algunas extensiones bloquean WebRTC por completo.
Configuraciones seguras con proxy
Hay tres enfoques que funcionan, con costes distintos. Desactivar WebRTC evita la fuga y rompe todos los sitios que lo necesitan. Obligar a WebRTC a usar solo la ruta del proxy (el modo «seguro con proxy» de algunos navegadores) mantiene las llamadas funcionando cuando el proxy admite UDP o TURN y, en caso contrario, no produce ningún candidato público. Dejar que WebRTC se comporte con normalidad solo es correcto cuando el proxy transporta todo el tráfico, como suele hacer una VPN a nivel de sistema.
Cuál es el adecuado depende del trabajo. Para un perfil de navegador aislado que debe parecer estar en un único lugar, la regla es simple: la dirección que expone WebRTC debe ser la misma que ve el servidor web, o ninguna. Cualquier otra cosa es una contradicción que un sitio puede detectar sin ninguna herramienta especial.
Cómo leer el resultado
Un diagnóstico muestra los candidatos que observó en unos segundos y compara cualquiera de ellos que sea público con la dirección desde la que se accedió a la página. «Ninguna expuesta», con algunos candidatos enmascarados, es un resultado normal y sano para un navegador que mantiene WebRTC dentro del proxy. Una dirección pública distinta de la de la página es lo que hay que corregir.
