Fuga de IP y DNS en WebKit: cómo afecta a los usuarios de iCloud Private Relay

Un nuevo informe publicado en el blog de investigación de seguridad Mysk describe una filtración de IP y DNS con origen en WebKit, el motor de navegador que impulsa Safari y, según las normas de la App Store de Apple, cualquier otra aplicación de navegador en iPhone y iPad, incluidos los navegadores proxy de terceros que la gente usa específicamente para ocultar su ubicación y su actividad de red. El hallazgo es significativo porque debilita precisamente la protección de privacidad que estas herramientas prometen, revelando la dirección IP real de un usuario o sus consultas DNS a un sitio web o a un observador de red incluso cuando hay activo un túnel de tipo proxy o VPN.

WebKit es el motor de navegador de Apple, y como Apple exige que todos los navegadores de iOS —ya sea Safari, Chrome para iOS o un navegador proxy dedicado a la privacidad— rendericen las páginas a través de WebKit en lugar de su propio motor, cualquier filtración dentro de WebKit afecta potencialmente a todos los navegadores de la plataforma, no solo a Safari. Ese único punto de fallo hace que esta categoría de error sea más grave en iOS que un fallo comparable en un ordenador de escritorio, donde los navegadores incorporan sus propios motores independientes.

La filtración que describe el informe se centra en cómo ciertas solicitudes de red —en particular las vinculadas a la resolución DNS y a determinadas API de WebKit— pueden eludir el túnel que establece un navegador proxy o el propio Relay Privado de iCloud de Apple. El Relay Privado está diseñado para enrutar el tráfico web de un usuario a través de dos relés separados, de modo que ni el proveedor de red ni el sitio de destino puedan ver a la vez la identidad del usuario y el sitio visitado.

Cuando se produce una filtración de DNS o IP, esa separación se rompe. Un sitio web o una red situada entre el usuario e internet puede llegar a ver la dirección IP real del usuario, u observar qué dominios resuelve el dispositivo, incluso cuando el usuario cree que su tráfico está anonimizado detrás del relé o del túnel proxy. Para alguien que usa estas herramientas precisamente para evitar ser rastreado o geolocalizado, ese es exactamente el modo de fallo que intentaba prevenir.

Este tipo de filtración no es exclusivo de WebKit en la historia de las herramientas de privacidad de los navegadores; las filtraciones de IP basadas en WebRTC y las filtraciones por precarga de DNS han afectado durante años a configuraciones de VPN y proxy en otros motores de navegador, a menudo porque una función diseñada para el rendimiento —resolver un nombre de dominio con antelación, o establecer una conexión entre pares antes de que sea necesaria— nunca se auditó para ver cómo se comporta cuando el navegador supuestamente debe tunelizar todo a través de un punto de salida separado.

Lo que hace especialmente vulnerables a los navegadores proxy en iOS es que, por lo general, no pueden sustituir WebKit por su propia pila de red como sí puede hacer un navegador de escritorio que incorpora su propio resolutor DNS. Están limitados en gran medida a configurar lo que se le proporciona a WebKit, lo que significa que una filtración en la propia lógica de gestión de solicitudes de WebKit es muy difícil de sortear para un navegador proxy de terceros por sí solo, y en la práctica requiere una corrección de Apple.

Para los usuarios del Relay Privado de iCloud, la exposición es más acotada pero igualmente notable, ya que el Relay Privado se presenta como la garantía propia de Apple frente a exactamente este tipo de protección. Una filtración que permite a un sitio de destino ver la dirección IP real detrás del Relay Privado debilita la función específica que Apple comercializa como una mejora de privacidad para los suscriptores de iCloud+, en lugar de un remedio improvisado por un desarrollador externo.

Los investigadores de seguridad que estudian esta categoría de errores suelen recomendar una respuesta por capas en lugar de confiar en una sola herramienta: combinar un proxy o relé con un proveedor de DNS configurado para bloquear filtraciones, probar la existencia de filtraciones con herramientas específicas basadas en el navegador antes de confiar en una configuración, y tratar la garantía de cualquier herramienta de privacidad como provisional hasta que investigadores independientes hayan intentado romperla en condiciones de red reales.

Para los usuarios cotidianos que no son investigadores de privacidad, la conclusión práctica es más modesta: los navegadores proxy y el Relay Privado elevan de forma notable la barrera frente al rastreo casual, pero no son una garantía absoluta frente a un observador de red o un sitio web suficientemente decidido, y los usuarios con necesidades agudas de anonimato —periodistas, activistas, personas que huyen de la vigilancia— deberían tratar cualquier herramienta a nivel de navegador como una capa dentro de una defensa más amplia, no como toda la defensa.

Apple tiene un historial de corregir problemas de WebKit una vez que se divulgan de forma responsable, y el patrón habitual para una filtración de este tipo es una corrección incluida en una actualización posterior de iOS y Safari, en lugar de un reconocimiento público del mecanismo subyacente. Hasta que llegue ese parche, el mensaje central del informe es un recordatorio de que "privado" y "cifrado" no son automáticamente sinónimos de "sin filtraciones", ni siquiera para herramientas diseñadas específicamente para impedir este tipo exacto de exposición.