"Te roban todos los datos en WiFi público" — eso era verdad en 2010, cuando la mayoría del tráfico era HTTP sin cifrar. Hoy ~95% del tráfico web es HTTPS, y los ataques catastróficos de sniffing de paquetes (¿alguien dijo Firesheep?) mayormente no funcionan. Pero "el WiFi público ya es seguro" también está mal. Los riesgos que quedan son reales, solo que distintos de los que esperarías.
Qué solía ser peligroso
A finales de los 2000 y principios de los 2010, el ataque canónico de WiFi público era simple: captura de paquetes abierta (Wireshark o una herramienta estilo Firesheep) en la red de una cafetería, y leer todo lo que no fuera HTTPS. La mayoría de webs de entonces usaban HTTPS solo para las páginas de login y mandaban todo lo demás en texto plano — incluidas las cookies de sesión. Un atacante podía agarrar una cookie de sesión de Facebook de alguien en el mismo WiFi y suplantarlo en minutos.
Este ataque efectivamente ya no funciona en la web moderna. La migración a HTTPS (impulsada por Let's Encrypt, los avisos de los navegadores sobre HTTP, y el boost de ranking SEO que Google dio a los sitios HTTPS) estaba mayormente completa para 2018. El email, la banca, las redes sociales, y casi todos los sitios grandes son solo-HTTPS.
Qué es de verdad peligroso ahora
1. Exposición de metadatos (SNI + DNS + IP)
Incluso con HTTPS, tu tráfico filtra metadatos en texto plano:
- SNI: el handshake TLS incluye el hostname al que te conectas. Un atacante en el WiFi puede ver "te conectaste a bankofamerica.com" aunque no pueda ver el contenido de la página.
- Consultas DNS: si usas el resolver DNS del WiFi (por defecto), cada dominio que consultas es visible en texto plano para quien corra ese resolver.
- IPs de destino: visibles en las cabeceras de paquete. Menos preciso que el SNI pero igual indicativo.
Resultado: un observador aprende qué sitios visitas, cuándo, y cuántos datos fluyen. No aprende qué haces en esos sitios — pero el metadato solo a menudo basta.
2. Puntos de acceso gemelos malvados
Un atacante crea un AP falso con el mismo SSID que el legítimo (ej., "Starbucks_Free" o "HotelWiFi") y espera a que los dispositivos se conecten solos. Los dispositivos en general prefieren señales más fuertes, así que un atacante físicamente cerca del objetivo puede ganar la carrera.
Una vez en el AP falso, el atacante controla:
- Las respuestas DNS (puede redirigirte a sitios de phishing).
- El portal cautivo (puede presentar páginas de login falsas para cosechar credenciales).
- El tráfico en texto plano (cualquier conexión no-HTTPS).
- Intentos de SSL stripping (forzando downgrades a HTTP en sitios que no fuerzan HSTS).
Los ataques de gemelo malvado son más comunes en aeropuertos, hoteles y congresos que en cafeterías al azar, pero no son raros.
3. Manipulación de portal cautivo
La página de "clic para aceptar términos" del WiFi de hotel funciona interceptando el tráfico HTTP y redirigiéndolo a la página de login. La tecnología es benigna per se, pero depende de que el HTTP en texto plano sea interceptable.
Un operador malicioso puede:
- Inyectar JavaScript o ads en la página del portal cautivo (algunos hoteles e ISPs lo han hecho comercialmente).
- Presentar una página de login falsa que cosecha credenciales.
- Usar el redirect del portal cautivo para hacer fingerprint de tu dispositivo.
No puedes evitar el portal cautivo — lo necesitas para tener internet — pero la exposición de seguridad se limita a la interacción con el portal.
4. SSL stripping (mayormente mitigado)
El SSL stripping intenta hacer downgrade de tu conexión HTTPS a HTTP interceptando el redirect inicial. Los navegadores modernos y HSTS (HTTP Strict Transport Security) protegen contra esto para la mayoría de sitios grandes. Pero los sitios sin HSTS, o las conexiones de primera visita a sitios nuevos, aún pueden ser strippeados.
5. Descubrimiento de red y ataques laterales
Una vez en una red WiFi, tu dispositivo puede ser detectable para otros dispositivos de esa red — según la configuración del AP. Si el aislamiento de cliente no está activado, otros dispositivos pueden:
- Escanear puertos abiertos en tu dispositivo.
- Intentar explotar vulnerabilidades conocidas.
- Sondear servicios compartidos (impresoras de red, compartición de archivos, AirDrop, etc.).
Los defaults de los SO modernos hacen que la mayoría de estos ataques fallen (sin shares de archivos abiertos, los firewalls bloquean puertos por defecto), pero los dispositivos con firmware viejo o configuraciones raras son más vulnerables.
Qué hace un VPN con todo esto
| Amenaza | HTTPS solo | HTTPS + VPN |
|---|---|---|
| Sniffing en texto plano | Protegido | Protegido |
| Metadatos SNI / DNS / IP | Se fuga | Cifrado en el túnel |
| AP gemelo malvado | Parcial (HTTPS avisa por el cert) | El túnel sale en el VPN, no en el AP local |
| SSL stripping | Mayormente protegido (HSTS) | Da igual — el túnel es el cert |
| Abuso de portal cautivo | Vulnerable | El VPN no se activa hasta pasar el portal — ojo |
| Ataques laterales de red | Vulnerable | El VPN no ayuda (lo hace el firewall del dispositivo) |
En resumen: un VPN es protección significativa en WiFi público para la capa de metadatos y contra ataques de AP fraudulento. No es magia. No reemplaza los firewalls del dispositivo, las actualizaciones del SO, ni el comportamiento sensato (no metas contraseñas antes de que el VPN esté conectado).
Guía práctica
- Conéctate al WiFi.
- Pasa el portal cautivo si lo hay.
- Inmediatamente conecta tu VPN antes de abrir cualquier otra cosa.
- Activa el kill switch para que el tráfico se bloquee si el VPN se cae.
- Verifica con nuestro chequeo de IP que el túnel está activo.
- Evita loguearte en nada sensible en la breve ventana antes de que el VPN esté conectado (mayormente durante la fase del portal cautivo).
Para instrucciones paso a paso específicas de ClownVPN, mira nuestra guía práctica de WiFi público.