Riesgos del Wi-Fi público en 2026

El artículo estándar sobre riesgos de Wi-Fi público ha sido aproximadamente el mismo desde 2014. ¡Hackers en cafeterías! ¡Sniffeando tus paquetes! ¡Robando tus passwords del banco! ¡Comprá una VPN! La mayor parte de eso ya no es preciso. El despliegue de HTTPS mató los ataques fáciles. Las amenazas que quedan son reales y distintas, y los consejos enlatados no se han puesto al día.

Esta es la visión 2026 de los riesgos del Wi-Fi público. Qué es genuinamente peligroso, qué es mayormente exageración, dónde ayudó WPA3, qué no protege HTTPS, y las capas defensivas reales. Menos alarmismo, más precisión.

De dónde vino el viejo consejo

Las guías de ataque a Wi-Fi público de 2010-2016 asumían algunas cosas que eran verdaderas en ese momento:

• La mayoría de los sitios web eran HTTP por defecto. Un observador pasivo en la red podía leer formularios de login, cookies, y contenidos de página.
• Las advertencias del navegador sobre problemas HTTPS eran inconsistentes. Los usuarios hacían click a través de errores de certificado rutinariamente.
• Los ataques a nivel red (envenenamiento ARP, gemelo malvado) eran fáciles con herramientas off-the-shelf (Firesheep, el Pineapple). Cualquiera con una laptop y software gratis podía montarlos.

En ese entorno, el consejo "usá una VPN en Wi-Fi público" era esencialmente correcto. El riesgo independiente era lo suficientemente alto como para que aun atacantes casuales causaran daño real.

El mundo cambió. Para fines de los 2010s, la cobertura HTTPS de la web abierta cruzó el 80%. Los navegadores dejaron de permitir a los usuarios hacer click a través de advertencias de certificado sin override explícito. Bancos, redes sociales, proveedores de email todos se movieron a HTTPS-only con HSTS. La superficie de ataque para la versión fácil del sniffing de Wi-Fi público colapsó.

Qué maneja HTTPS ahora

En 2026, más del 95% de la web es HTTPS. Para una sesión típica de navegación en Wi-Fi público:

• Los contenidos de página están encriptados. Un observador de red no puede leer la página que estás viendo, el formulario que estás enviando, o las cookies que mandás.
• Los tokens de autenticación están encriptados. Las cookies de sesión que habrían sido el robo fácil en la era Firesheep están dentro de TLS. Leerlas del cable no es factible.
• La identidad del servidor se verifica. El handshake TLS autentica el destino. Un man-in-the-middle tendría que o conseguir un certificado válido para el destino (difícil) o engañarte para que aceptes uno inválido (los navegadores ya no te dejan hacer esto casualmente).

El framing "mirá tu password del banco siendo robado" común en publicidades viejas de VPN está mayormente obsoleto. La banca es sólo HTTPS. El navegador rehusará conectarse con un certificado inválido. La superficie de ataque para ese escenario específico se encogió dramáticamente.

Qué no maneja HTTPS

Las amenazas son distintas ahora, no se fueron. Específicamente:

SNI es texto plano

El handshake TLS incluye el hostname destino (Server Name Indication) en claro. Un observador de red ve nytimes.com aunque no pueda leer el artículo. Aprenden qué sitios visitás, cuándo, en qué orden, por cuánto tiempo.

Encrypted Client Hello (ECH) arregla esto. Cloudflare, Mozilla, y Google lo soportan. La mayoría de la web aún no, a 2026. SNI es texto plano para la mayoría de los sitios que visitás.

DNS es texto plano

Antes de que tu navegador pueda conectarse a un sitio, tiene que resolver el nombre. El DNS texto plano va al resolver que el operador de red configuró, usualmente el servidor DNS del operador. Ven cada dominio que resolvés. Algunos captive portals interceptan y modifican respuestas DNS para redirigirte.

DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT) arreglan esto. Firefox hace DoH por defecto en algunas regiones. Chrome lo hace para resolvers conocidos capaces de DoH. La mayoría de los usuarios en la mayoría de las plataformas siguen mandando DNS texto plano al operador de red.

Forma del tráfico

Aun con todo lo demás encriptado, los tamaños de paquete y patrones de timing filtran información. Cargar un video específico de YouTube tiene un fingerprint reconocible de solicitudes de segmento. Streamear un episodio de Netflix tiene uno distinto. Un observador sofisticado con herramientas de análisis de tráfico puede identificar sitios específicos e incluso videos específicos desde la forma del tráfico, especialmente para destinos de alto tráfico.

Esto es raro para usuarios individuales en Wi-Fi de cafetería. Es real para adversarios a nivel de estado en redes a escala nacional.

IP destino

Aun el DNS encriptado no oculta la IP destino. Los routers a lo largo del camino la ven porque tienen que reenviar paquetes. Para sitios en infraestructura dedicada, el mapeo IP-a-dominio es trivialmente derivable.

Qué es realmente peligroso en Wi-Fi público en 2026

Las amenazas realistas hoy, rankeadas por probabilidad:

1. Access points gemelos malvados

Un access point pícaro broadcastea un nombre de red idéntico a uno legítimo ("Hotel-Guest", "Airport-Free-WiFi", "Starbucks"). Tu dispositivo se conecta, frecuentemente automáticamente porque recuerda el SSID de una visita previa. El atacante controla la red y puede interceptar tu tráfico.

Por qué sigue funcionando en 2026: WPA3 mitiga algunos ataques pero no previene la suplantación de SSID. Los clientes Wi-Fi siguen confiando en SSIDs. La mayoría de las redes públicas son abiertas o basadas en PSK, ninguna de las cuales previene la suplantación. El Wi-Fi enterprise moderno usa autenticación basada en certificados que sí lo previene, pero el Wi-Fi de consumo no.

Lo que un gemelo malvado puede hacer: ver todo tu tráfico no encriptado (mayormente DNS), servirte un captive portal que inyecta contenido, intentar MITM de conexiones TLS (lo que mayormente falla por validación de certificado, pero funciona contra clientes mal configurados), y loguear toda metadata sobre tu actividad.

Lo que no puede hacer: leer tu contenido HTTPS, leer el contenido de tu túnel VPN, o reemplazar certificados TLS en los que confiás.

2. MITM de captive portal

Las redes de hoteles y aeropuertos usan captive portals: redirects HTTP a una página de aterrizaje donde aceptás términos o pagás por acceso. El mecanismo de captive portal inherentemente hace MITM al menos a una conexión HTTP, porque así funciona el redirect.

Algunos captive portals van más allá. Inyectan scripts en páginas HTTP. Sirven contenido modificado. Corren analíticas que loguean cada dominio al que conectás. Han sido documentados vendiendo datos de navegación y revendiendo datos de consultas DNS.

Una VPN bypassea el MITM de captive portal limpiamente: una vez que el túnel está arriba, el captive portal sólo ve bytes encriptados. El desafío es que los captive portals usualmente requieren una red funcionando para autenticarse, y necesitás autenticarte antes de que la VPN pueda establecer el túnel. Patrón estándar: conectate a la red, autenticate al captive portal, luego inmediatamente levantá la VPN.

3. Recolección de datos del operador de red

Las redes de hotel, redes de aeropuerto, y servicios de Wi-Fi público rutinariamente loguean metadata de conexión: cada dominio resuelto, cada IP a la que se conectó, tiempo, duración, cuentas de bytes. Algunos venden esta data a data brokers. Algunos la entregan a programas de vigilancia gubernamental. Algunos simplemente la guardan indefinidamente sin política.

Esto no es hipotético. Ejemplos documentados incluyen:

• Cadenas hoteleras mayores fueron descubiertas corriendo inspección profunda de paquetes que perfila tráfico de huéspedes.
• Redes de aeropuerto fueron descubiertas logueando DNS y SNI de TLS para partners de marketing y vigilancia.
• Proveedores de Wi-Fi de cafeterías (los contratistas de franquicia, no las tiendas individuales) tienen prácticas similares de datos.

Una VPN mueve el límite de confianza del operador de red a tu proveedor VPN. Si eso es una mejora depende de cuánto confiás en cada uno. Para la mayoría de los usuarios, una VPN paga con una política real de privacidad es más confiable que el operador random de red de hotel.

4. Intentos de bypass de certificate-pinning del captive portal

Algunos captive portals tratan de hacer MITM a HTTPS haciéndote instalar un certificado. Esto es raro en redes públicas (es una red flag obvia y la mayoría de los usuarios declina) pero pasa ocasionalmente en redes gestionadas (cadenas hoteleras, sedes de conferencias, redes del empleador). Si instalás el certificado, el operador de red puede hacer MITM a todas tus conexiones TLS. No instales certificados de redes que no controlás.

5. Routers de consumo comprometidos

Algo de Wi-Fi público corre en routers de consumo que han sido comprometidos por malware. El malware redirige DNS a servidores de inyección de anuncios, redirige dominios bancarios específicos a páginas de phishing, o instala monitoreo persistente. Esto es más común en hoteles y departamentos de alquiler donde el equipo es más viejo y rara vez se actualiza.

Una VPN bypassea esto enteramente una vez que el túnel está arriba.

Qué es mayormente exageración

Algunos items que se citan pero son menos riesgo real en 2026:

Sniffing de paquetes de passwords texto plano

El demo clásico Firesheep / aircrack-ng era aterrador en 2010 porque la mayoría de los sitios mandaba data de login en cleartext. En 2026, los destinos que importan (bancos, email, redes sociales, servicios de streaming) son sólo HTTPS con HSTS. El ataque no funciona contra sitios modernos.

Eavesdropping con Wireshark

Sí, Wireshark funciona. Captura tráfico. Lo que captura es mayormente encriptado por TLS, con la fuga de metadata ya discutida (SNI, DNS, IP). El demo "mirá mi email siendo robado en Wi-Fi público con Wireshark" ya no funciona contra servicios modernos. La versión análisis-de-tráfico de esto es real pero requiere más sofisticación que la que un atacante casual trae.

"Hackers" en el sentido casual

La imagen de alguien con un hoodie en una cafetería robando tus datos con una laptop está mayormente desactualizada. El atacante casual perdió la mayor parte de su superficie de ataque. Las amenazas que quedan son:

• Vigilancia a nivel operador de red (recolección de datos, MITM por los operadores mismos).
• Atacantes sofisticados (gemelo malvado, análisis de tráfico), que existen pero son raros.
• Adversarios a nivel de estado, que existen para algunos usuarios pero no son el escenario de Wi-Fi público de cafetería.

WPA3 y qué cambió

Estatus de despliegue WPA3 a 2026:

• WPA3 Enterprise está ampliamente desplegado en redes enterprise modernas (corporativas, universitarias, gubernamentales). Usa autenticación basada en certificados y es significativamente más seguro que WPA2.
• WPA3-Personal para casa y negocios pequeños está menos universalmente desplegado. Los routers más nuevos lo soportan. Los clientes más viejos (cualquier cosa pre-2019 típicamente) no, así que la mayoría de las redes caen a modo mixto WPA2.
• Hotspots públicos son en gran medida aún abiertos o WPA2-PSK en 2026. La transición ha sido lenta porque requiere upgrades tanto de router como de cliente, y el mercado de consumo se actualiza lentamente.

Lo que WPA3 arregla que afecta al Wi-Fi público: agrega Simultaneous Authentication of Equals (SAE), lo que hace los ataques offline contra el password de la red mucho más difíciles. Para redes genuinamente abiertas (sin password), WPA3 tiene Opportunistic Wireless Encryption (OWE), que encripta el link Wi-Fi aun en redes sin clave compartida.

Lo que WPA3 no arregla: suplantación de SSID (ataques gemelo malvado), MITM de captive portal, recolección de datos del operador de red. WPA3 asegura el link de radio al access point. No te asegura contra el operador de ese access point.

Las capas defensivas que importan

En orden aproximado de importancia para Wi-Fi público en 2026:

1. HTTPS-Everywhere por defecto

Los navegadores modernos (Firefox, Chrome, Safari, Edge) defaultan a HTTPS. Algunos tienen un modo que rechaza HTTP enteramente. Habilitalo. Firefox tiene "HTTPS-Only Mode". Chrome tiene "Always Use Secure Connections". Safari lo tiene incorporado.

Esto maneja el 95% de la superficie fácil de ataque de Wi-Fi público gratis.

2. DNS-over-HTTPS

Encripta tus consultas DNS para que el operador de red no pueda leerlas o redirigirlas. Firefox lo hace por defecto en algunas regiones. Chrome lo hace cuando tu resolver configurado soporta DoH. Configurá tu DNS del SO a un resolver capaz de DoH (Cloudflare 1.1.1.1, Google 8.8.8.8, NextDNS, Quad9) para protección a nivel sistema.

Esto maneja el vector de fuga DNS y los ataques de redirect DNS.

3. Una VPN

Los vectores que quedan (SNI texto plano, logueo de tráfico a nivel IP, ataques gemelo malvado, vigilancia del operador de red, análisis de forma de tráfico) se mitigan mejor con un túnel VPN. Una vez que el túnel está arriba, el operador de red sólo ve bytes encriptados fluyendo al servidor VPN.

Una VPN es la única capa defensiva más efectiva para Wi-Fi público en 2026 porque cubre todo lo que HTTPS no. Tenemos una pieza sobre VPN para Wi-Fi de hotel y avión que entra en el caso de uso específico.

El kill switch importa acá. Si la VPN se cae, tu tráfico no debería filtrar. Tenemos una pieza más profunda sobre kill switches explicados.

4. Sentido común sobre redes

No te conectes a redes que no reconocés. No autoconfíes en una red sólo porque el SSID matchea con un lugar donde estuviste antes (los ataques gemelo malvado se basan en esto). Verificá el nombre de la red con el local si importa. No instales certificados de redes que no controlás.

Escenarios específicos

Wi-Fi de hotel

La peor categoría. Las redes de hotel tienen un historial largo y documentado de: vigilancia, venta de datos, inyección de captive portal, inspección profunda de paquetes, y aislamiento débil de red entre huéspedes. Usá una VPN. Tenemos una pieza más profunda sobre Wi-Fi de hotel específicamente.

Wi-Fi de aeropuerto y avión

Aeropuerto: problemas similares al hotel. Usá una VPN. Avión: lo mismo más la restricción de que las conexiones satelitales pueden ser lentas y el captive portal frecuentemente bloquea cualquier cosa que no sea HTTP y HTTPS en puertos estándar. WireGuard sobre UDP frecuentemente funciona. OpenVPN sobre TCP 443 es el fallback. VLESS Reality sobre TCP 443 también funciona y es la más confiable en captive portals agresivos.

Wi-Fi de cafetería

Menor riesgo que el hotel porque el operador de red (el franquiciado de la cafetería) usualmente es menos profesional sobre recolección de datos. Aún así: SNI es visible, DNS puede ser interceptado, y los ataques gemelo malvado son posibles en áreas concurridas. Una VPN es razonable. HTTPS más DoH es el mínimo.

Wi-Fi de conferencia

Frecuentemente bien gestionado (Wi-Fi enterprise real con WPA3-Enterprise) o terriblemente gestionado (quien sea que tendió ethernet a un access point de consumo). Difícil decir desde afuera. Defaultá a una VPN.

Wi-Fi de biblioteca y universidad

Frecuentemente corre detección de intrusiones que puede flagear conexiones VPN. La VPN sigue funcionando en la mayoría de los casos. Si tu biblioteca o universidad tiene una política de bloqueo de VPN y la hace cumplir, ese es su propio problema para navegar.

Setup práctico

Para la mayoría de los usuarios, un setup defensivo razonable de Wi-Fi público se ve como:

1. Modo HTTPS-only del navegador habilitado.
2. DNS-over-HTTPS configurado a nivel SO (o en Firefox si sólo navegás).
3. Una VPN con kill switch, configurada para auto-conectarse en redes no confiables.
4. Soporte de cliente WPA3 habilitado (el SO maneja esto; los dispositivos modernos ya lo hacen).
5. Selección de red apagada para SSIDs públicos que no usás activamente (para que tu dispositivo no auto-conecte a gemelos malvados de "Starbucks" mientras caminás por una calle).

Este stack maneja esencialmente todas las amenazas realistas de Wi-Fi público en 2026. Nada de esto es exótico.

Conclusiones prácticas

• Los ataques fáciles de Wi-Fi público de 2014 están mayormente muertos. HTTPS los mató.
• Las amenazas que quedan son reales pero distintas: APs gemelos malvados, MITM de captive portal, vigilancia del operador de red, análisis de tráfico.
• WPA3 ayuda pero no cambia mucho el cuadro de amenazas del Wi-Fi público, porque la mayoría de las redes públicas son aún WPA2 o abiertas.
• HTTPS, DoH, y una VPN son las tres capas que manejan las amenazas reales de 2026.
• Un kill switch importa porque los túneles se caen, y una ventana de fuga durante una caída derrota a la VPN.

Si estás eligiendo una VPN específicamente para uso en Wi-Fi público, nuestra pieza ¿realmente necesito una VPN? trata esto como el caso independiente más fuerte. La prueba gratis de 7 días te da tiempo para ver si funciona en las redes que efectivamente usás.