Fundadores de Psylo revelan tres fugas de proxy de WebKit que afectan a iCloud Private Relay

Why it matters

A privacy browser can configure its proxy correctly and still lose control when WebKit or an operating-system service opens a separate connection. Psylo's patch protects its users, while the reported behavior also reaches other proxy browsers and Apple's iCloud Private Relay.

Talal Haj Bakry (@hajbakri) and Tommy Mysk (@tommymysk), los fundadores detrás del navegador de privacidad Psylo, revelaron tres comportamientos de WebKit el 4 de agosto que, según ellos, pueden eludir los proxies a nivel de navegador y exponer la red real de un usuario. La pareja también lanzó Psylo 1.3.1, que bloquea o desactiva las funciones afectadas.

La investigación comenzó con una queja de cliente inusualmente específica. Un usuario de Psylo notó que la información DNS se filtraba en ciertos sitios web mientras que en otros sitios el comportamiento fue el esperado, según la divulgación técnica de Bakry y Mysk. Los fundadores rastrearon ese informe hasta la precarga de DNS, y luego encontraron dos rutas adicionales que involucraban passkeys y WebTransport.

Esa secuencia importa para Psylo. Bakry y Mysk construyeron el navegador sobre la premisa de que cada pestaña aislada, que llaman un silo, puede enrutar a través de un proxy separado manteniendo sus cookies y almacenamiento por separado. Mysk dice que su Private Proxy Network ofrece más de 40 ubicaciones de proxy.

Los fundadores desarrollaron Psylo a partir de años de investigación sobre privacidad móvil, lanzando el navegador en junio de 2025 después de que una versión beta anterior excediera su alcance original. Su hallazgo más reciente provino de pruebas del framework de Apple debajo de ese producto, donde el código de la aplicación tiene autoridad limitada sobre conexiones iniciadas en otra parte de WebKit o del sistema operativo.

Tres rutas que evaden el proxy

La API WKWebsiteDataStore.proxyConfigurations de WebKit permite que una aplicación envíe su tráfico web a través de servidores proxy especificados. En un navegador enfocado en la privacidad, el resultado previsto es sencillo: los sitios web reciben la dirección IP del proxy, mientras que las solicitudes DNS se originan desde la infraestructura del proxy.

Bakry y Mysk dicen que tres características se escapan de esa ruta:

• Precarga de DNS: Un sitio web puede usar una indicación HTML para pedirle al navegador que resuelva un nombre de host antes de que sea necesario. Los investigadores encontraron que WebKit envía esta búsqueda a través de la ruta DNS ordinaria del dispositivo. Un sitio que controla el nombre de host de destino podría, por lo tanto, observar la infraestructura DNS normal del visitante en lugar de la del proxy.
• Solicitudes de origen relacionadas de WebAuthn: Esta función de passkeys verifica si dominios relacionados están autorizados para compartir una credencial. Los investigadores dicen que el servicio de credenciales del sistema operativo recupera el archivo de validación directamente, fuera del proxy configurado del navegador, exponiendo la dirección IP del dispositivo al servidor de destino.
• WebTransport: Esta API establece conexiones de baja latencia sobre HTTP/3 y QUIC. Bakry y Mysk encontraron que WebKit crea la conexión sin aplicar la configuración de proxy de la sesión del navegador, permitiendo que el servidor reciba la dirección IP real del dispositivo.

Las cronologías difieren. Las Solicitudes de origen relacionadas de WebAuthn han estado disponibles desde iOS 18.0, según la divulgación. La precarga de DNS llegó a iOS en septiembre de 2025 con iOS 26.0, tras un cambio en WebKit que añadió soporte para indicaciones explícitas dns-prefetch. WebTransport se lanzó públicamente con iOS 26.4 en marzo de 2026, como documentan las notas de la versión de WebKit.

Bakry y Mysk publicaron una página de prueba de concepto que intenta cada técnica. Su divulgación es la base de las afirmaciones sobre cómo se comportan las tres rutas.

Las reglas de Apple para navegadores amplían la exposición

Las Directrices de revisión de apps de Apple generalmente exigen que las aplicaciones que navegan por la web usen el framework WebKit apropiado. Los desarrolladores pueden solicitar privilegios para motores de navegador alternativos en la Unión Europea y Japón, pero la mayoría de los navegadores de privacidad en iOS siguen dependiendo del comportamiento de red de WebKit.

Esa dependencia deja a los desarrolladores de navegadores con proxy responsables de un límite de privacidad que no controlan por completo. Una aplicación puede configurar correctamente el tráfico de página ordinario mientras una función de WebKit o un servicio del sistema operativo crea una conexión separada sin las mismas configuraciones de proxy.

Bakry y Mysk dicen que el problema alcanza a los navegadores Tor en iOS que se basan en la misma API de proxy. Contactaron al Tor Project y a los desarrolladores de Onion Browser, un navegador iOS de código abierto que enruta el tráfico a través de Tor. Los investigadores identificaron una excepción más estrecha: el nivel de seguridad Silver de Onion Browser desactiva WebTransport mediante la configuración Lockdown Mode de Apple, impidiendo esa ruta de conexión en particular.

Las VPN a nivel de sistema operan de manera diferente. Debido a que tunelizan el tráfico a nivel del dispositivo, Bakry y Mysk dicen que las tres elusiones de proxy a nivel de aplicación no se escapan de un túnel VPN correctamente configurado.

Private Relay comparte el límite

Los fundadores también probaron los comportamientos con iCloud Private Relay de Apple, la función iCloud+ diseñada para proteger la navegación en Safari mediante dos relays separados. Apple dice que Private Relay cifra los registros DNS y separa la identidad de un usuario de los sitios web solicitados.

Bakry y Mysk dicen que la precarga de DNS, la obtención de validación de WebAuthn y las conexiones WebTransport se realizan fuera de la ruta normal de tráfico de Safari manejada por Private Relay. Según sus pruebas, la precarga de DNS expuso la infraestructura DNS del dispositivo, mientras que las otras dos técnicas expusieron su dirección IP real.

La divulgación pone a Apple y a un fabricante de navegadores mucho más pequeño en el mismo lado del límite subyacente. Al 5 de agosto, la ficha de App Store de Psylo en EE. UU. mostraba 37 calificaciones y una puntuación de 4.4. Esa huella pública es modesta, sin embargo un informe de un usuario de Psylo llevó a sus dos fundadores a examinar un comportamiento que afecta al propio servicio de privacidad de pago de Apple.

Psylo sacrifica compatibilidad por valores predeterminados más seguros

Psylo 1.3.1 bloquea por completo las sugerencias HTML de precarga de DNS. También desactiva WebTransport y WebAuthn de manera predeterminada en cada silo, según la divulgación de Mysk y las notas de la versión en la App Store de Apple.

Esas decisiones cierran las rutas reportadas dentro de Psylo, a la vez que generan costos de compatibilidad. Desactivar WebAuthn puede impedir que fluyan los procesos de passkeys. Desactivar WebTransport puede afectar a sitios que dependen de la API de red más reciente. Psylo permite a los usuarios volver a habilitar cualquiera de las funciones para un silo individual, haciendo que la exposición de privacidad sea una configuración explícita en vez de una consecuencia invisible de cargar una página.

El parche muestra la ventaja que puede tener un producto enfocado cuando falla una abstracción a nivel de plataforma. Bakry y Mysk no pudieron cambiar la implementación de red de WebKit, así que redujeron el conjunto de funciones expuestas por Psylo y dieron a los usuarios controles por sesión. El problema más difícil está debajo de la app: los desarrolladores de navegadores necesitan que las configuraciones de proxy rijan cada conexión que una página pueda desencadenar, incluyendo trabajo delegado a servicios del sistema operativo.