- Se reveló que el servicio de WiFi gratuito para mensajería a bordo de British Airways en realidad permite un acceso limitado a Internet mediante un filtrado basado en dominios específicos
- El autor manipuló el campo SNI (Server Name Indication) de TLS para engañar al sistema de la aerolínea y hacerle creer que era tráfico de mensajería, logrando así acceder a sitios web comunes
- Para ello, configuró
wa.me (dominio de WhatsApp) como SNI y desvió el tráfico usando un proxy HTTPS y stunnel
- Como resultado del experimento, los sitios basados en texto (como Hacker News) cargaron con normalidad, pero las imágenes y el contenido pesado se transfirieron lentamente por una limitación de ancho de banda
- Este caso muestra la debilidad del filtrado basado en TLS SNI y la necesidad de tecnologías como ECH (Encrypted Client Hello) para mitigarlo
Cómo funciona el WiFi gratis para mensajería
- British Airways ofrece WiFi gratis solo para mensajería a los miembros de “The British Airways Club”
- El registro puede hacerse en el portal a bordo sin verificación por correo; WhatsApp, Signal y WeChat funcionaban, pero Discord estaba bloqueado
- El autor se preguntó cómo permitía el servicio solo las apps de mensajería
- Concluyó que no se trataba de una simple restricción de tráfico, sino de una lista blanca de dominios basada en el campo SNI de TLS
- Un análisis con Wireshark mostró que al conectarse a
example.com se producía un reinicio de TCP después del Client Hello
- Esto indica un método que bloquea dominios no permitidos usando el valor de SNI, visible durante el handshake de TLS
Cómo funciona el filtrado basado en SNI
- El SNI de TLS envía en texto plano el nombre de dominio al que se quiere conectar antes de que empiece el cifrado
- Gracias a eso, un ISP o administrador de red puede ver a qué sitio intenta acceder un usuario
- British Airways registró en una lista blanca solo los dominios relacionados con apps de mensajería y reinicia el resto de las conexiones
- El autor confirmó que también se bloqueaban las conexiones directas por IP sin SNI (
openssl s_client -connect)
- Es decir, la ausencia de SNI también se considera tráfico anómalo
Experimento de manipulación de SNI
- El autor intentó una conexión TLS configurando
wa.me (dominio de WhatsApp) como SNI
- Aunque el certificado del servidor no era para
wa.me, la conexión era posible si el cliente ignoraba la discrepancia del certificado
- Como resultado, el sistema de BA lo confundió con tráfico de mensajería y permitió el túnel TLS
- Luego escribió directamente solicitudes HTTP y recibió con éxito contenido de su propio servidor (
saxrag.com)
- Este experimento demostró que si se engaña solo el campo SNI, es posible transportar tráfico arbitrario
Evasión completa con un proxy HTTPS
- El autor configuró un servidor proxy HTTPS usando
tinyproxy y stunnel
stunnel agrega una capa TLS para hacer que el cliente parezca estar conectándose a wa.me
- En el comando
curl, usó la opción --resolve para mapear wa.me a la IP de su VPS
- Así, el SNI se establece como
wa.me, pero la conexión real se hace a su servidor personal
- Ignoró los errores del certificado TLS con
--proxy-insecure y logró hacer solicitudes externas a través del proxy
- Al consultar
ifconfig.co, se devolvió la IP del VPS, confirmando que el proxy funcionaba
Prueba en un vuelo real
- En el vuelo de regreso, se conectó al WiFi con la misma configuración y recibió una respuesta HTTP 200 correcta mediante
curl
- Después configuró el proxy HTTPS en el navegador (Chromium) y agregó
wa.me al archivo hosts
- Como resultado, logró acceder al sitio web de Hacker News, y las páginas basadas en texto cargaron correctamente
- En Wireshark confirmó el descifrado TLS usando
SSLKEYLOGFILE
- Las imágenes y el contenido pesado cargaban lentamente, línea por línea, lo que sugiere la existencia de una limitación de ancho de banda
- Esto sugiere que BA combina el filtrado por SNI con restricciones de velocidad de tráfico
Experimento con ECH (Encrypted Client Hello)
- El autor probó directamente la tecnología ECH, diseñada para resolver el problema de exposición del SNI en TLS
- Generó un ECHConfig con
wa.me como public_name y lo aplicó en Firefox
- Como resultado, el SNI externo seguía siendo
wa.me, pero el ClientHello interno incluía el dominio real (rfc5746.mywaifu.best)
- Se estableció una conexión TLS válida con un certificado de Let’s Encrypt
- Curiosamente, también funcionó en un puerto no estándar (7443), evadiendo el filtrado de British Airways
- El autor plantea la posibilidad de que el ECHConfig se haya transmitido mediante DNS-over-HTTPS (DoH)
Limitaciones del SNI e implicaciones de seguridad
- El SNI es originalmente solo una pista para que el servidor seleccione el certificado adecuado
- En entornos donde se controlan tanto cliente como servidor, se puede insertar cualquier valor de SNI
- Esto implica que los sistemas de censura o las soluciones de detección de amenazas pueden tener falsos positivos si dependen demasiado del filtrado basado en SNI
- Un autor de malware podría usar un SNI disfrazado como dominio inofensivo al conectarse a su servidor C&C
- Por lo tanto, las políticas de seguridad de red necesitan análisis adicional del tráfico y verificación de capas de cifrado además del SNI
Conclusión
- El WiFi gratuito de British Airways permite solo tráfico de mensajería mediante filtrado de dominios basado en SNI y limitación de ancho de banda
- Sin embargo, el experimento demostró que al manipular el SNI es posible disfrazar tráfico HTTPS arbitrario como si fuera mensajería
- Este caso muestra una limitación estructural del diseño de TLS y subraya la necesidad de adoptar ECH
- Los operadores de red y responsables de seguridad deben reconocer la fragilidad del filtrado dependiente de SNI
- Aunque es un caso técnicamente interesante de evasión, también es un ejemplo de investigación que debe ir acompañado de consideraciones de seguridad y ética
1 comentarios
Opiniones de Hacker News
Algunas aerolíneas, probablemente American Airlines, usan firewalls de Fortinet, así que no solo revisan el SNI, sino también el nombre del host y la autoridad certificadora del certificado del servidor
Mi amigo lo evadió usando el SNI de aa.com y retransmitiendo tal cual el handshake TLS 1.2 real de aa.com
Después, en la etapa de datos cifrados, ignoraba ese handshake y simplemente lo usaba como un túnel cifrado
Hoy en día, si usas TLS 1.3, el certificado va cifrado y el firewall no puede ver su contenido, así que se puede evitar este problema
Si llega una solicitud para un SNI específico sin la clave secreta, hace proxy de todo el handshake SSL hacia un sitio web señuelo
En caso contrario, funciona como un proxy normal disfrazado de tráfico SSL
Originalmente fue creado para evadir el GFW (Gran Cortafuegos) de China, pero según dijo mi amigo, al poner Google Analytics como SNI también funcionó con el firewall a bordo de American
El Wi‑Fi y la app funcionan gratis, pero la mayor parte del tráfico está bloqueada
Revisando con Wireshark, vi que solo permiten unos cuantos paquetes al inicio de la conexión TCP, y luego inspeccionan el ClientHello para dejar pasar solo dominios en lista blanca
La app del crucero funciona porque el dominio de la empresa está en la lista blanca
Este tipo de falla conviene aprovecharla con discreción. Si se hace demasiado conocida, la van a cerrar, y sería una pena
Aunque el plato y la tarifa sean caros, vale totalmente la pena como una especie de “declaración de independencia” frente a la naviera
Hoy en día los portales cautivos bloquean casi todo el tráfico externo, pero todavía hay muchos que siguen siendo vulnerables
Recomiendo SoftEther: gracias a la función Azure Relay funciona muy bien incluso en redes con lista blanca
Aún no he probado llegar al punto de usar iodine para comunicación bidireccional por DNS, pero aunque sea lento, probablemente funcionaría en la mayoría de los casos
Si repites el inicio del proceso de pago, puedes evadirlo así
El arranque era lento por tener que probar muchos puertos, pero la tasa de éxito era sorprendentemente alta
Pero hoy en día muchas redes solo permiten tráfico DNS y bloquean resolvers arbitrarios
Si alguien lograra hacer una VPN TCP-over-WhatsApp, estaría buenísimo
No era DNS, sino HTTP(S) sobre túnel UDP, y me sentí bastante orgulloso cuando logré dejarlo listo dentro del límite de 30 minutos de Wi‑Fi gratis en el aeropuerto de Stansted
Mencioné una vulnerabilidad grave en su sitio web y lo dejaron pasar diciendo algo como “si fuera importante, saldría en un pentest”
Terminó sin que ninguna de las dos partes quedara muy impresionada
La seguridad del Wi‑Fi a bordo es básicamente un mecanismo para sacar dinero, separado de la seguridad real de la empresa
Muchas empresas creen que con hacer un pentest anual ya cumplieron con la seguridad, mientras que los ingenieros que realmente conocen el producto no consiguen aprobación para invertir
La industria tecnológica es un sector de altos ingresos, así que pagar la tarifa del Wi‑Fi no debería ser problema
Es una herramienta para hacer proxy del tráfico a través de otros nodos, y la implementé yo mismo para entender mejor las redes
También buscaba evadir la ley de verificación de edad del Reino Unido
Enlace a GitHub
Me gusta ese rato de desconexión del mundo. Por eso no me entusiasma que todo el mundo termine usando Wi‑Fi gratis
Si tú no quieres conectarte, no lo hagas. Que otros lo usen no te afecta en nada
Tengo activado el plan de mensajería gratis y estoy usando un túnel WireGuard, así que no parece que el firewall esté diseñado para bloquearlo a la perfección
Recuerdo haberlo intentado antes y no me funcionó muy bien