Wi‑Fi público peligroso incluso con HTTPS: ataques reales, casos y protección en 2026

Wi‑Fi público: lo que parece seguro pero en realidad no lo es tanto

Nos encanta el internet gratis en cafés, hoteles y aeropuertos. ¿Quién no valora la comodidad? Te conectas y listo, a trabajar. Pero esa comodidad suele pagar con seguridad. El Wi‑Fi público es como una tetera en un hostal: parece limpio, pero no sabes quién la usó ni qué hizo ayer. Y sí, aunque veas el candadito HTTPS, no es una armadura al 100%. En 2026, los atacantes son más inteligentes, las herramientas más accesibles y los riesgos mucho mayores.

¿Suena alarmante? Un poco. Pero por eso aquí te lo explicamos paso a paso: por qué HTTPS no es garantía total, qué ataques realmente funcionan hoy, cómo los atacantes aprovechan captive portals y puntos de acceso falsos, qué puede y qué no puede hacer una VPN, y cómo podemos reducir esos riesgos casi a cero, con cabeza y sin paranoia.

Hablaremos claro, con ejemplos, cifras y casos concretos. Para que no solo asientas con la cabeza, sino que realmente cambies tus hábitos. ¿Listo? Vamos allá.

Por qué el Wi‑Fi “gratis” rara vez es gratis

Pagas con tus datos cuando usas Wi‑Fi público. Los portales de autorización recogen tu correo, número de teléfono, huellas del dispositivo y a veces intentan suscribirte a notificaciones push. Los administradores ven metadatos del tráfico: qué dominios visitas, cuándo y cuánto. ¿Y si quien está al otro lado no es el administrador sino un atacante conectado a la misma red? Ahí hablamos de ataques MITM, suplantación DNS, phishing y robo de sesiones.

Cómo los atacantes “ven” tu dispositivo

El router o un punto de acceso falso monitorean ARP, DHCP, DNS y los handshakes TLS. Incluso sin descifrar HTTPS, se puede deducir mucho por los metadatos: SNI (si no está cifrado), IPs, tamaño de paquetes, frecuencia de solicitudes. Súmale tráfico público de apps y protocolos no seguros y el rompecabezas encaja demasiado bien.

El mito de “tengo HTTPS, estoy seguro”

Nos encanta el candadito en la barra de direcciones. Pero HTTPS protege el canal "navegador – servidor", no "punto de acceso – ética del dueño de la red". Si un atacante cambia el DNS y te lleva a un clon phishing con certificado válido (sí, pasa con cadenas comprometidas, errores de configuración o certificados raíz maliciosos confiados en tu dispositivo), tu confianza juega en tu contra. Y si el ataque ocurre antes de que cargue HTTPS (como vía captive portal), ni siquiera verás el candado.

Cómo funciona HTTPS en 2026 y por qué no es la solución mágica

En 2026 la mayoría de navegadores usan TLS 1.3 por defecto y buscan implementar Encrypted Client Hello (ECH) para ocultar el SNI. Mejoró, pero no es perfecto. El diablo está en las transiciones y excepciones: redirecciones, el primer clic sin protección, contenido mixto, HSTS incompleto, apps antiguas, configuración débil en routers. También está el problema de confianza en certificados raíz y perfiles MDM instalados.

TLS 1.3, ECH, HTTP/3 y la realidad en los cafés

HTTP/3 sobre QUIC acelera y cifra el transporte, ECH oculta el dominio en el saludo cifrado del cliente. Perfecto en teoría. Pero las redes en cafés suelen limitar o moldear QUIC para ahorrar y filtrar, forzando a los clientes a volver a HTTP/2 o incluso HTTP/1.1. Ahí aparecen “agujeros” de compatibilidad y los atacantes se aprovechan, bloqueando protocolos nuevos o modificando respuestas en el primer contacto.

HSTS ayuda, mientras no lo deshabiliten

HSTS dice al navegador “siempre usa HTTPS”. Funciona bien si la web ya está en la lista precargada o el usuario ha entrado antes por HTTPS. Mal, si es la primera visita y la red impone un redirect por HTTP. Esa ventana de ataque es pequeña pero real. Imagínate además que el router en la red elimina activamente encabezados HSTS (actuando como proxy) o fuerza downgrade. Raro, pero ocurre en redes “grises” con filtrado agresivo.

El problema de los certificados confiables y perfiles MDM

A veces, en dispositivos hay certificados raíz extra confiables: por VPN pirata, perfiles corporativos o antivirus desactualizados. En Wi‑Fi público un atacante podría ofrecer “actualizar certificado para internet” vía un captive portal falso. Si aceptas, MITM en TLS es pan comido. Vimos casos así en hoteles y redes turísticas.

Amenazas reales en redes públicas: de MITM a suplantación DNS

La lista de ataques es larga, pero estos son los más comunes en campo en 2026: MITM por ARP spoofing o proxy, DNS spoofing con suplantación de dominios y bloqueo de DoH, Evil Twin clonando SSID, captive portals phishing con scripts proxy, y secuestro de sesiones en apps sin pinning estricto.

MITM vía ARP spoofing

Clásico: el atacante convence a tu dispositivo de que él es el gateway por defecto. El tráfico pasa por él. Puede ver dominios, IPs, intentos de handshake. Si logra colocar un certificado proxy o hace que el cliente baje a HTTP, empieza una inspección profunda. Buenas noticias: los SO modernos mejoran la defensa, pero las redes públicas a menudo desactivan protección por “compatibilidad”.

DNS spoofing y bloqueo de DoH/DoT

Todos aman DNS over HTTPS, pero muchos portales bloquean DoH/DoT antes de pasar el captive y luego “olvidan” reactivarlo. En ese hueco el atacante puede cambiar respuestas: preguntas por bank.example, recibes bank-secure-login.example. Después aplica SSL stripping o un certificado válido pero raro y defectuoso. Sin atención del usuario o protección en apps, desastre seguro.

Evil Twin y clon en dos minutos

Crear un punto con el mismo SSID, máscara de MAC y señal más fuerte toma minutos y unos pocos clics. Este “gemelo” intercepta tráfico sin que notes, especialmente si tienes auto-conexión activada. En 2026 es más fácil por dispositivos baratos y software que copia parámetros de red automáticamente. Y sí, muchos dispositivos aún se apegan a la señal más potente sin preguntar.

SSL stripping y reset de HSTS: cómo se ve en la vida real

SSL stripping es cuando te bajan de HTTPS a HTTP antes de que la protección actúe. Como atraer a alguien a una escalera mal iluminada: un paso en falso y estás en problemas.

Escenario 1: redirección antes de HTTPS

Escribes la dirección sin https. El atacante intercepta y responde con su web HTTP falsa que parece legítima. El botón “Entrar” dirige al sitio HTTPS real, pero los datos del formulario ya están capturados. Visualmente parece un parpadeo rápido, el usuario no nota nada y la sesión está comprometida.

Escenario 2: bugs de compatibilidad y HSTS cortado

Algunos sitios aplican HSTS parcialmente: subdominios sin protección, tiempo de vida corto, sin preloading. El atacante inyecta un subdominio sin HSTS donde te autenticas por costumbre o por un anuncio abierto. Luego hace su juego con cookies, tokens y manipulación social.

Escenario 3: certificado de usuario

A través de un captive portal falso te ofrecen “acceder a internet” instalando un “certificado de acceso”. Un solo toque y listo, MITM incluso en HTTPS. Menos común en 2026, pero aún frecuente en zonas turísticas y eventos masivos. Sobre todo si la red promete cupones, descuentos o “Wi‑Fi premium sin anuncios”.

Ataques a captive portal sin trucos: cómo engañan incluso a los atentos

El portal de autorización es un mecanismo legal, pero los atacantes lo adoran porque normaliza los redireccionamientos. ¿Ves una pantalla rara? Claro, es el portal. Y haces clic. Ahí inyectan todo: certificados y “actualizaciones de navegador”.

Páginas phishing disfrazadas de red

Logo del café, nombre del aeropuerto, hasta el esquema de colores. Súper convincentes. El portal pide correo electrónico, contraseña de red social “para entrar”, número de tarjeta “para verificar 1 euro” o Apple/Google ID “para sincronizar”. Te sorprenderías de cuánto gente cae. Hemos visto conversiones del 3-7% en eventos masivos, y eso es mucho.

Ataques push y trampas QR

Código QR en la mesa, "conéctate al Wi‑Fi rápido". Escaneas y te llevan a una página que pide instalar perfil o suscribirte a notificaciones. Luego llegan push con enlaces phishing: "Tu sesión expiró", "Confirma el pago". Funciona incluso horas más tarde, cuando ya estás en casa. Muy molesto.

Scripts proxy y recolección de tokens

Algunos portales inyectan scripts proxy que monitorean tus visitas hasta que el navegador cachea redirecciones. Descubren hábitos, acumulan identificadores y aumentan riesgos de re-targeting. No siempre delito, a veces marketing agresivo, pero igual problema.

Rogue AP y Evil Twin: ¿notarías la suplantación?

Parece que estás conectado a “Airport_Free_WiFi”. Pero en realidad estás en “Airport_Free_WiFi” en la laptop de un atacante a dos metros, con señal más fuerte. La red funciona, rápido, el café está caliente — todo perfecto. Hasta que es demasiado tarde.

Señales de suplantación

Certificados inestables, redirecciones extrañas, desconexiones inesperadas de DoH/DoT, avisos constante de “Esta conexión puede ser monitoreada”, portales emergentes en cada sitio nuevo. También solicitudes inesperadas de instalar perfiles, cambiar proxy o “actualizar seguridad”. Si parpadeaste dos veces, ya es sospechoso.

Por qué WPA2‑Enterprise no siempre salva

Redes corporativas con 802.1X y EAP son un avance, pero el problema es que usuarios ignoran verificar el nombre del servidor RADIUS. Evil Twin mete un RADIUS falso con certificado auto-firmado y los clientes aceptan. En 2026 los móviles advierten mejor, pero el factor humano no falla.

WPA3, SAE y la realidad

WPA3‑Personal con SAE es más difícil de romper por fuerza bruta, pero no evita MITM a nivel IP y DNS si el atacante controla el punto de acceso. El cifrado cliente-AP no es escudo contra todo el mundo, especialmente si el atacante está en el AP.

VPN en 2026: fortalezas, limitaciones y mitos

VPN es una herramienta poderosa, pero no una varita mágica. Cifra tu tráfico del punto de acceso al servidor VPN, oculta consultas DNS (si está bien configurado) y anula muchos escenarios MITM. Pero no protege del phishing, no arregla lo que instalaste tú mismo (certificado malicioso) y a veces falla con captive portals.

Qué protege realmente la VPN

Con la VPN activa desde que entras a la red, todo el tráfico va por un túnel cifrado. El atacante no ve dominios, contenido ni solicitudes. Buenas VPN incluyen DNS propio dentro del túnel, protegiendo contra DNS spoofing. Además, el kill switch corta conexión si falla el túnel. En 2026 protocolos como WireGuard e IKEv2/ChaCha20 son rápidos incluso en móviles, y algunos proveedores usan QUIC para conexión estable en redes inestables.

Dónde la VPN es débil

¿Página phishing? La VPN no detecta falsificaciones con TLS válido. ¿Instalación de perfil malicioso? VPN no se entera. ¿Robo de tokens en apps sin pinning? Si la app permite MITM con certificados personalizados, la VPN no ayuda. Y también la VPN puede no activarse antes de pasar el captive portal, dejando ventana abierta para ataques.

Split-tunneling y configuraciones delicadas

Muchos activan split-tunneling "para velocidad". Eso encanta a los atacantes: parte del tráfico escapa del túnel y puede ser interceptado. Para Wi‑Fi público es mejor full-tunnel estricto, prohibiendo redes locales y con kill switch activado. No es lo más cómodo, pero duermes tranquilo.

Prácticas recomendadas: lista sin extremos

Sin tecnicismos. Pasos y hábitos que realmente funcionan. Primero reglas básicas, luego configuraciones avanzadas y aspectos empresariales.

Reglas básicas para todos

• No ingreses contraseñas ni datos de tarjeta en Wi‑Fi público salvo que sea imprescindible. Si es necesario, solo vía VPN y en dominios que conozcas bien.
• Desactiva auto-conexión a redes abiertas. Mejor conéctate manualmente y olvida la red tras usarla.
• Atento a alertas de certificados. Cualquier “error de seguridad” en red pública es bandera roja. Cierra la pestaña.
• No instales perfiles, certificados raíz, “aceleradores de internet” ni “actualizaciones de navegador” desde portales.
• Usa un navegador sandbox separado para redes públicas, sin sesiones ni logins guardados.

Configuraciones técnicas que ayudan

• Activa VPN con inicio automático y kill switch. Apaga split-tunneling en redes públicas.
• Forza que el sistema use DoH/DoT dentro del VPN. Bloquea DNS local si el proveedor intenta imponerlo.
• Configura bloqueo de instalación de certificados raíz sin PIN o biometría. Revisa certificados confiables cada trimestre.
• Usa en navegador modo HTTPS-Only. Instala extensiones de aislamiento de sesión (contenedores) y gestores con detección de phishing.
• Activa MFA/2FA, preferiblemente con llaves físicas o passkeys. Códigos OTP por SMS son mínimo, pero mejor que nada.

Para móviles y laptops

• En iOS y Android: bloquea sincronización en segundo plano de apps pesadas en redes abiertas sin VPN.
• En Windows y macOS: habilita firewall, bloquea conexiones entrantes en redes públicas, desactiva compartición de archivos y AirDrop/Nearby Share temporalmente.
• Crea un perfil Wi‑Fi “Public”: sin auto-conexión, con recordatorio para activar VPN y con restricciones en redes locales.

Para empresas y equipos

• Políticas MDM: prohíbe instalación de certificados raíz personalizados, obliga VPN always-on, controla lista de CA confiables.
• Usa SASE/ZTNA con chequeos de posture device: solo dejan entrar dispositivos con parches actuales y cifrado de disco activo.
• Implementa filtrado DNS vía resolvers seguros, bloqueando dominios recién registrados (DGA, fast-flux).
• Capacita al personal cada seis meses. Muestra demo real de ataque Evil Twin y la precaución se dispara.

Casos reales: así es en la práctica

Historias concretas, sin rodeos. Aprender de los errores ajenos sale más barato.

Caso 1: aeropuerto y “acceso rápido sin anuncios”

Red con portal de autorización. Cerca, un atacante levantó un Evil Twin con el mismo SSID y señal más fuerte. Portal idéntico, pero ofrece “acelerador” instalando perfil. Diez por ciento de usuarios aceptó. Después MITM incluso en sitios bancarios, robo de tokens, redirección a phishing. Resultado: varias cuentas hackeadas y correos corporativos filtrados.

Caso 2: cafetería y SSL stripping “en el primer clic”

Un usuario puso la dirección sin https y el atacante metió un proxy HTTP en la primera conexión. Capturaron la forma de login, redirigieron al sitio real y el usuario no notó nada. Dos horas después detectaron movimientos raros en su cuenta. Salvó MFA y registro de actividad, pero la mala sensación quedó.

Caso 3: conferencia, código QR y phishing push

Los organizadores pusieron códigos QR “conéctate al Wi‑Fi”. Alguien cambió algunas pegatinas. La página falsa suscribía a notificaciones push. Al día llegaron mensajes “Confirma acceso”. Conversión del 4%. Suficiente para ruido en redes sociales y un par de historias tristes.

Tendencias en 2026 que cambian el juego

Sin entender el contexto, quedas anclado en consejos viejos. En 2026 hubo tres cambios clave: adopción masiva de ECH, passkeys en lugar de contraseñas e integración de ZTNA en dispositivos corporativos. Parece burocracia, pero es un gran salto en seguridad.

ECH y ocultar el SNI

El amplio soporte de ECH reduce las fugas de dominios en el handshake inicial. Esto baja la eficacia de algunos tipos de reconocimiento pasivo en redes públicas. Pero si ocurre fallback a protocolos viejos (común en puntos de acceso “antiguos”), la protección se debilita. Por eso evita desactivar protocolos modernos por “compatibilidad” cuando puedas.

Passkeys y WebAuthn

Cuando usas dispositivo y biometría en lugar de contraseña, “robar la clave” ya no funciona. Incluso si escuchan el tráfico, no obtienen el secreto para entrar. Combina passkeys con restricciones geográficas y por dispositivo y el Wi‑Fi público pierde miedo.

ZTNA y SASE en la práctica

Las empresas dejaron atrás los túneles VPN para proxys internos con chequeo de contexto: quién eres, desde qué equipo, si tiene parches, cifrado activo, y no está rooteado. En redes públicas este método reduce mucho el éxito del phishing social: incluso si roban la contraseña, no dan acceso a los servicios.

Configuraciones paso a paso en plataformas populares

Un poco de tierra firme: qué tocar hoy para estar más seguro mañana. Sin pantallazos, pero con pasos claros.

iOS 18 y iPadOS

• Ajustes — Wi‑Fi — Tu red — Auto-conexión: apagado para redes abiertas. Dirección Wi‑Fi privada: activada.
• Ajustes — VPN — Añadir configuración: elige protocolo WireGuard o IKEv2. Activa “Conectar bajo demanda” y “Bloquear tráfico sin VPN” (kill switch vía perfil MDM o config).
• Ajustes — Safari — Avanzado — Modo solo HTTPS: activado. Desactiva perfiles externos, revisa certificados confiables.

Android 15

• Red e internet — Wi‑Fi — Ajustes — Auto-conexión: desactivado para abiertas. Dirección MAC aleatoria: activada.
• VPN: instala cliente con soporte always-on y bloqueo de tráfico sin VPN. Permite DNS por VPN, bloquea DNS local.
• Chrome — Ajustes de seguridad — Usar DNS seguro — activa DoH (vía VPN si soporta). Activa protección contra phishing y contraseñas seguras.

Windows 12

• Red e internet — Wi‑Fi — Administrar redes conocidas: elimina abiertas y desactiva auto-conexión.
• Firewall: perfil “Público” — bloquea conexiones entrantes. Desactiva compartir archivos e impresoras.
• VPN: usa WireGuard/IKEv2, activa “Desconectar si falla VPN”. Aplica política “Permitir tráfico solo por VPN” en redes públicas.

macOS 15

• Red — Wi‑Fi — Avanzado: elimina redes abiertas y desactiva “Conexión automática” para desconocidas.
• Firewall — Activar — Bloquear todas las conexiones entrantes en perfiles públicos. Desactiva AirDrop a “Solo contactos” o del todo.
• Configura VPN para “Conectar al detectar red pública”. En Safari activa “Preferir HTTPS” y protección contra seguimiento.

Phishing y ingeniería social: por qué la gente hace clic

Tecnología se contrarresta con ajustes. Gente, no tanto. Hacemos clic cuando estamos apurados, cansados, nos prometen algo o “parece lógico”. El Wi‑Fi público es perfecto para presionarnos: estás en fila, el café se enfría, mandan mensajes “¿y qué pasa?”. Ahí nos atrapan.

Cómo protegerte

• Para un momento tres segundos. Cualquier portal desconocido: pausa. Si pide contraseña de correo, casi seguro es fraude.
• Busca señales de “phishing fácil”: dominios raros con guiones, zonas extrañas, alertas en el navegador. Si dudas, verifica usando datos móviles, no esa red.
• Usa gestor de contraseñas: no rellenará en dominios erróneos. Si no hay autocompletado, revisa la barra de direcciones.

Apps móviles — un dolor oculto

No todas aplican pinning estricto de certificado. Eso significa que en MITM con certificado usuario pueden “creer” al atacante. En 2026 muchos corrigieron esto, pero no todos. Usa servicios críticos en navegador con passkeys y configuraciones estrictas, no en apps dudosas.

Errores que repetimos una y otra vez

Con sinceridad: todos fallamos. Pongamos las cosas claras y dejemos de hacerlo.

Auto-conectarse a todo lo que aparezca

Desactívalo globalmente. Mejor dedicar 10 segundos a elegir red que 10 horas a recuperar cuenta.

Ignorar errores de certificado

“Ah, debe ser fallo del café”. No. 9 de 10 es justo la advertencia del navegador. Vete.

Contraseñas de servicios laborales en redes abiertas

Si no es permitido, no lo hagas. Si es urgente, usa ZTNA/VPN corporativa con MFA y navegador confiable.

Para desarrolladores y administradores: qué hacer hoy

Los usuarios seguirán usando Wi‑Fi público. Nuestra tarea es que, aunque las condiciones no sean ideales, no tengan miedo.

Para web

• HSTS estricto con includeSubdomains y preloading. Calcula mínimo 1-2 años.
• Evita contenido mixto. Usa Content Security Policy y modo HTTPS obligatorio.
• Activa WebAuthn/passkeys. Minimiza dependencia de contraseñas.
• Monitorea subdominios y typosquatting. Alertas automáticas para dominios clonados.

Para apps móviles

• Pinning de certificado con rotación de claves. Manejo de certificados raíz no confiables.
• Bloqueo en dispositivos rooteados/jailbreak para funciones críticas. Incorpora protección MITM en el SDK.
• Fail-closed: no continuar si el certificado es dudoso.

Para redes corporativas

• Políticas MDM, ZTNA, posture device y control de certificados. Bloquea proxies y perfiles no firmados.
• Logs y detección de anomalías: picos en errores TLS, bloqueos DoH, múltiples logins a portales— señales clave.

Lista rápida antes de conectarte a Wi‑Fi público

1. ¿Es realmente la red correcta? Pregunta al personal.
2. ¿Auto-conexión desactivada? Perfecto.
3. ¿VPN se activa sola? ¿Kill switch activo?
4. Navegador en modo HTTPS-Only, gestor de contraseñas operando?
5. No instales perfiles o certificados, aunque “parezca necesario”.
6. Evita pagos y acciones administrativas si puedes esperar.

Qué hacer si crees que te están atacando

No entres en pánico. El plan es simple. Pasos cortos y estarás seguro.

Paso a paso

• Desconéctate inmediatamente de Wi‑Fi y cambia a datos móviles.
• Cambia contraseñas de cuentas clave, cancela sesiones y tokens.
• Revisa certificados confiables y perfiles instalados. Borra lo sospechoso.
• Activa alertas de accesos, añade o renueva passkeys, actualiza MFA.
• Repasa logs: accesos desde regiones extrañas, intentos de recuperación. Reporta si hace falta.

Mínimo riesgo con sentido común

El Wi‑Fi público es como un taxi de noche: a veces lo necesitas, pero sin exagerar. Un poco de alerta, ajustes correctos y buenas costumbres te ponen en el 10% superior de los objetivos menos “apetecibles”. Los atacantes prefieren presas más fáciles.

Acuerdos claros: no vamos a caer en paranoia, pero tampoco a cerrar los ojos. Activamos VPN antes, no instalamos perfiles dudosos, no ignoramos alertas, usamos passkeys y ZTNA, y limpiamos certificados cada seis meses. Los detalles cuentan. Y sí, el café seguirá caliente, lo prometemos.

FAQ: preguntas frecuentes sobre Wi‑Fi público y seguridad

¿Es suficiente en 2026 solo HTTPS para estar seguro?

No. HTTPS es la base, pero no protege contra phishing, no evita redirecciones captive y no ayuda si instalaste un certificado malicioso. Es parte importante, pero no la fortaleza completa. Complementa con VPN, modo HTTPS-Only, passkeys y sano escepticismo.

¿La VPN soluciona todos los problemas del Wi‑Fi público?

No. VPN cifra y oculta DNS muy bien, pero no arregla phishing ni ingeniería social. No sirve si tú mismo confiaste en un atacante vía perfil. Usa VPN como base, pero no como única medida.

¿Qué tan peligrosos son los captive portals?

Tan peligrosos como que hagas clic sin leer. Un portal legal es aceptable, pero normaliza la idea de un “popup raro”. Esa ventana es la más atacada. No des contraseñas para otros servicios, no instales perfiles ni certificados. Nunca.

¿Vale la pena desactivar la auto-conexión a redes abiertas?

Sí. Es la mejor forma de evitar engancharte a un Evil Twin. Conéctate manualmente, verifica el nombre con el personal, y olvida la red tras usarla. Además, activa la dirección MAC aleatoria (Private Address).

¿Qué es más importante: DoH/DoT o VPN?

Si eliges uno, VPN, porque encapsula tanto DNS como todo el tráfico. Pero ideal es usar ambos juntos: DoH/DoT dentro de la VPN. Lo importante es que el sistema no caiga al DNS local del proveedor en redes públicas.

¿Son necesarios los passkeys si ya hay buenas contraseñas y 2FA?

Sí. Los passkeys reducen casi a cero el riesgo de phishing porque están ligados a dominio y dispositivo. Combinados con 2FA, aumentan mucho el “costo” para el atacante.

¿Se puede usar servicios bancarios seguro en Wi‑Fi público?

Sí, pero mejor por datos móviles o dentro de VPN configurada estrictamente con modo HTTPS-Only y gestor de contraseñas. Si ves alguna alerta por certificado o redirección extraña, sal inmediatamente y cambia de red.