ICloud Private Relay: Falla en WebKit expone direcciones IP reales

En la arquitectura de privacidad contemporánea, la promesa de anonimato que ofrece Apple a través de icloud private relay ha representado uno de los pilares comerciales más agresivos de la marca. Diseñado como una función clave dentro de las suscripciones pagas de iCloud+, este servicio promete enmascarar las direcciones IP de los usuarios y cifrar el tráfico de navegación en Safari mediante una arquitectura de doble salto (dual-hop). Sin embargo, una minuciosa investigación técnica revelada por los reconocidos investigadores de ciberseguridad Tommy Mysk y Talal Haj Bakry ha dejado al descubierto grietas estructurales profundas en el motor de navegación de Apple, WebKit. Estas vulnerabilidades permiten a cualquier sitio web evadir sistemáticamente la protección de icloud private relay y obtener la dirección IP real de la conexión del usuario sin su conocimiento ni consentimiento.

El hallazgo resulta especialmente crítico debido a las reglas operativas de Apple. En los sistemas operativos iOS e iPadOS, la compañía exige que absolutamente todos los navegadores web utilicen el motor WebKit. Como consecuencia, el fallo no solo afecta a Safari, sino que compromete de manera uniforme a navegadores de terceros como Google Chrome, Mozilla Firefox, Microsoft Edge, Brave e incluso a soluciones enfocadas en el anonimato estricto como Onion Browser (la adaptación de Tor para iOS) y Psylo. Comprender la naturaleza técnica de estas filtraciones requiere analizar cómo WebKit procesa las solicitudes a nivel de sistema operativo y por qué los mecanismos de proxy integrados en las aplicaciones fallan al contener el tráfico de red.

Fallas estructurales en WebKit: cómo se vulnera icloud private relay

La investigación liderada por Mysk y Haj Bakry identificó tres mecanismos específicos dentro de WebKit que ignoran las configuraciones de proxy de la API WKWebsiteDataStore.proxyConfigurations. Estos vectores redirigen el tráfico de datos directamente desde el dispositivo del usuario hacia los servidores de destino, dejando al descubierto la IP real de la red local.

A continuación se detallan los tres vectores técnicos de fuga descubiertos:

• 1. Solicitudes de origen relacionado en WebAuthn (Integración de Passkeys):

  Este es el vector más severo y sigiloso. El estándar WebAuthn es la infraestructura subyacente de las llaves de acceso (passkeys), la tecnología impulsada por la industria para reemplazar las contraseñas tradicionales. Cuando un usuario navega por un sitio web que soporta —o simula soportar— passkeys, WebKit transfiere la gestión de la autenticación al servicio de credenciales del sistema operativo (credentiald en macOS/iOS). Debido a que este servicio opera fuera del proceso del navegador Safari, realiza peticiones HTTPS directas para descargar archivos de validación (como el archivo /.well-known/webauthn) sin pasar por el túnel cifrado de icloud private relay. Mediante el uso de llamadas con mediación condicional (mediation: "conditional"), un sitio web malicioso o de rastreo puede activar esta verificación en segundo plano. El proceso no muestra ninguna interfaz de usuario ni solicita confirmación biométrica, pero le entrega al servidor de destino la dirección IP pública real del dispositivo de forma instantánea.

• 2. Prefiltrado DNS (DNS Prefetching):

  El prefiltrado DNS es una técnica de optimización del rendimiento diseñada para acelerar la carga de páginas web al resolver preventivamente los nombres de dominio de las hipervinculaciones presentes en un sitio. La falla radica en que WebKit no canaliza estas consultas DNS a través del proxy de icloud private relay. En su lugar, delega la resolución al sistema de nombres de dominio predeterminado del dispositivo. Esto expone tanto las direcciones de los servidores DNS reales del usuario (que revelan su proveedor de servicios de Internet o ISP) como metadatos de ubicación geográfica precisa. Un sitio web puede insertar etiquetas HTML del tipo <link rel="dns-prefetch" href="..."> con subdominios únicos por visitante para rastrear conexiones reales fuera de la red privada.

• 3. Conexiones WebTransport (HTTP/3 directo):

  WebTransport es un protocolo moderno que permite comunicaciones bidireccionales y de baja latencia entre un navegador y un servidor mediante conexiones UDP sobre QUIC (HTTP/3). En la implementación de WebKit, las peticiones iniciadas a través del protocolo WebTransport evaden por completo la capa de abstracción de red configurada para los servidores proxy. Al abrir un socket directo hacia el servidor remoto, el tráfico no ingresa al túnel de retransmisión de doble salto, revelando inmediatamente la dirección IP real de origen en la cabecera de red.

El mito del “VPN de Apple”: Arquitectura de doble salto vs. Túneles a nivel de sistema

Uno de los mayores malentendidos entre los consumidores de tecnología radica en asumir que icloud private relay funciona como una Red Privada Virtual (VPN) tradicional. La diferencia arquitectónica entre ambas soluciones explica por qué estas vulnerabilidades en WebKit resultan tan devastadoras para los usuarios que buscan anonimato.

La arquitectura de icloud private relay utiliza un modelo de dos retransmisiones cifradas (dual-hop relays):

1. El Ingress Proxy (Primer salto): Operado por Apple, recibe la solicitud del usuario y conoce su dirección IP real, pero no puede ver el contenido de la URL de destino debido al cifrado.
2. El Egress Proxy (Segundo salto): Operado por socios de red independientes (como Cloudflare, Fastly o Akamai), descifra la dirección de destino y reenvía la petición al sitio web, pero solo ve la dirección IP asignada por el primer salto, desconociendo la identidad real del cliente.

Esta estructura garantiza en teoría que ninguna entidad —ni Apple, ni el socio de red, ni el sitio web visitado— pueda vincular simultáneamente quién es el usuario y qué sitio está visitando. Sin embargo, la limitación fundamental de este modelo radica en que opera estrictamente a nivel de aplicación (a través del motor WebKit en Safari) y no a nivel de interfaz de red del sistema operativo.

Por el contrario, una VPN profesional crea un adaptador de red virtual (interfaz TUN/TAP) en el núcleo del sistema operativo. Todo paquete de datos generado por cualquier proceso, servicio en segundo plano o API del sistema se captura, cifra y enruta de forma obligatoria a través del túnel VPN antes de salir del dispositivo. Dado que WebKit ejecuta llamadas al servicio de credenciales del sistema operativo fuera del contexto de la aplicación, las solicitudes de WebAuthn y WebTransport evaden el proxy de nivel de aplicación. En una VPN a nivel de sistema, este tráfico en segundo plano habría quedado inevitablemente dentro del túnel cifrado.

Consecuencias para el ecosistema iOS y navegadores de privacidad

La posición dominante de WebKit en el ecosistema de Apple magnifica el impacto de esta vulnerabilidad. Mientras que en sistemas operativos de escritorio como macOS o Windows navegadores como Firefox y Google Chrome utilizan sus propios motores de renderizado (Gecko y Blink, respectivamente) y gestionan las ceremonias de WebAuthn de manera interna, en iOS están forzados a subordinarse a las APIs de WebKit.

El caso de la red de anonimato Tor en iOS resulta ilustrativo. Onion Browser, la principal opción para navegar en la red Tor en dispositivos de Apple, se vio afectada de manera directa por las fugas de IP a través de WebAuthn y WebTransport. Esto significa que usuarios con necesidades críticas de seguridad —como periodistas, activistas o investigadores— habrían sufrido exposición no deseada de sus redes locales a pesar de estar utilizando protocolos de enrutamiento cebolla.

Por su parte, los propios desarrolladores de la aplicación de proxy Psylo reaccionaron neutralizando temporalmente estas tres funciones de WebKit dentro de su navegador mediante la desactivación de APIs vulnerables, una medida de contingencia que Apple aún no ha desplegado de forma global en iOS.

Guía de auditoría y mitigación para usuarios preocupados por su privacidad

Ante la falta de un parche de software inmediato por parte de Apple para reestructurar el manejo de proxies en WebKit, los usuarios que dependen de la ocultación de su dirección IP deben realizar una auditoría activa de su configuración de red y aplicar medidas preventivas de mitigación.

A continuación se presenta un plan de acción estructurado:

1. Realizar una auditoría de fuga mediante herramientas de prueba

Es indispensable verificar si el dispositivo actual expone la dirección IP real al interactuar con servicios de autenticación web. Se recomienda utilizar herramientas de prueba públicas desarrolladas por investigadores de seguridad (como leaks.psylo.app). Al visitar estas plataformas con icloud private relay activo, la herramienta intentará ejecutar ceremonias WebAuthn y solicitudes WebTransport silenciosas. Si la prueba despliega la IP pública asignada por el proveedor de Internet del usuario en lugar de la dirección del proxy de Apple, la conexión está comprometida.

2. Migrar a una VPN dedicada a nivel de sistema

Para garantizar que los servicios en segundo plano del sistema operativo no transmitan paquetes fuera del túnel seguro, es fundamental utilizar un servicio de VPN comercial o privado estructurado a nivel de red. Al activar una VPN con protocolo WireGuard o OpenVPN, la totalidad del tráfico UDP y TCP —incluidas las peticiones del servicio de credenciales para passkeys y las consultas de resolución DNS— quedará atrapada dentro del cifrado de la interfaz virtual.

3. Configurar DNS cifrado personalizado (DoH / DoT)

Para contrarrestar la fuga por prefiltrado DNS, los usuarios pueden instalar perfiles de configuración de DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT) de proveedores centrados en la privacidad como NextDNS o Cloudflare (1.1.1.1) a nivel de sistema operativo. Esto obliga al dispositivo a resolver las peticiones DNS mediante canales cifrados dedicados, reduciendo la exposición de metadatos frente a servidores DNS locales imprevistos.

4. Habilitar el Modo de Aislamiento (Lockdown Mode) en casos de alto riesgo

Para aquellos usuarios con un perfil de amenaza elevado, la activación del Modo de Aislamiento (Lockdown Mode) en iOS y macOS ofrece una capa de protección adicional. Este modo deshabilita de forma predeterminada varias APIs avanzadas de WebKit, incluyendo la ejecución arbitraria de ciertos protocolos de red como WebTransport y optimizaciones complejas de javascript, cerrando parcialmente los vectores de explotación más sofisticados.

Conclusión: El desafío de la privacidad transparente en Big Tech

La exposición de las falencias en el motor WebKit pone de relieve los límites inherentes a las soluciones de privacidad integradas comercialmente por las grandes corporaciones tecnológicas. Si bien icloud private relay supuso un avance significativo en la democratización del cifrado web para millones de usuarios cotidianos de Safari, la interacción compleja entre los estándares de autenticación modernos (como WebAuthn) y las arquitecturas de proxy de capa de aplicación demuestra que la comodidad y la seguridad absoluta rara vez convergen sin un diseño riguroso.

Hasta que Apple publique una actualización integral de iOS y macOS que obligue a los servicios del sistema operativo a respetar los límites de la API de proxy de WebKit, la recomendación para periodistas, profesionales de ciberseguridad y entusiastas de la privacidad es clara: no confiar de manera exclusiva en las herramientas de ocultación basadas en el navegador y adoptar cifrado de red a nivel de sistema mediante VPNs dedicadas. La verdadera privacidad digital requiere una postura proactiva de auditoría continua frente a la evolución del panorama de amenazas.