🌙 LATE NIGHT MODE ACTIVATED — THE CLOWN IS WATCHING 🌙
Inicio → Recursos → Seguridad → MITM

Ataques
man-in-the-middle.

Alguien se sienta entre tú y el sitio al que intentas llegar, retransmitiendo el tráfico en ambas direcciones y leyéndolo o modificándolo. El modelo de ataque clásico contra el que están diseñados los VPN y HTTPS. Aquí va la mecánica real.

La forma general del MITM

"Man-in-the-middle" describe cualquier ataque donde un adversario se posiciona entre dos partes que se comunican, intercepta los mensajes, y o bien escucha, modifica, o suplanta a una de las partes. Los objetivos clásicos son:

  • Tu dispositivo ↔ la web que visitas
  • Tu dispositivo ↔ tu resolver DNS
  • Tu dispositivo ↔ tu punto de acceso WiFi
  • Tu dispositivo ↔ tu ISP

Para que el ataque sea útil, el atacante o bien tiene que estar posicionado en una red que transitas (mismo WiFi, misma red local, controlando un hop del camino) o tiene que engañar a tu dispositivo para que rutee el tráfico por él.

Los mecanismos específicos

ARP spoofing

En una red local, los dispositivos usan ARP (Address Resolution Protocol) para mapear IPs a direcciones MAC. ARP se basa en la confianza — los dispositivos se creen entre ellos por defecto. Un atacante en el mismo WiFi puede emitir respuestas ARP falsas diciendo "yo soy el router", redirigiendo el tráfico de los demás dispositivos a sí mismo primero.

Una vez posicionado, el atacante reenvía el tráfico al router real (así que internet sigue funcionando) pero lo lee o modifica al vuelo. La detección es complicada para los usuarios finales — los SO modernos son ligeramente desconfiados de los cambios ARP no solicitados pero generalmente los aceptan.

DNS spoofing / secuestro de DNS

Dos variantes:

  • Spoofing: un atacante en tu red intercepta tus consultas DNS y devuelve respuestas falsas, mandándote a servidores controlados por el atacante en lugar de los reales. Crees que visitas bank.com pero visitas un clon del atacante.
  • Secuestro: un atacante compromete o controla el propio resolver DNS — típicamente controlando un AP WiFi malicioso o hackeando un router doméstico vulnerable.

El DNS spoofing solo no basta para derrotar HTTPS — el atacante aún necesita un certificado válido para el dominio spoofeado. Pero es un prerrequisito para muchos otros ataques (especialmente el phishing).

Punto de acceso fraudulento / gemelo malvado

Cubierto en detalle en riesgos del WiFi público. El atacante crea un AP WiFi falso con un SSID familiar, engaña a los dispositivos para que se conecten, y se vuelve el "router" para ese tráfico. Se combina de forma natural con ataques ARP y DNS ya que el atacante controla toda la red local.

SSL stripping

Se supone que HTTPS lo fuerza la web, no el atacante. El SSL stripping explota el hueco: cuando escribes "bank.com" en tu navegador, tu petición inicial va vía HTTP (puerto 80), y el sitio normalmente responde con un redirect a HTTPS. Un atacante puede interceptar esa petición HTTP inicial y servir su propia página por HTTP, sin escalar nunca a HTTPS.

El usuario ve una URL ligeramente distinta (sin icono de candado, sin HTTPS), pero la mayoría de usuarios no lo notan. Las cabeceras HSTS (HTTP Strict Transport Security) y la lista de preload de HSTS del navegador cierran este hueco para los sitios grandes. Para sitios más pequeños sin HSTS, el ataque aún funciona en las primeras conexiones.

Certificados falsos

HTTPS depende de que las Autoridades de Certificación (CAs) firmen certificados legítimos para los dueños de dominios. Si un atacante puede obtener un certificado válido para un dominio — o bien legítimamente (por compromiso) o explotando una CA con bugs — puede hacer MITM a conexiones HTTPS que parecen completamente legítimas al navegador.

Incidentes históricos:

  • DigiNotar (2011): CA holandesa comprometida; 500+ certificados falsos emitidos para Google, Yahoo, y otros. Usados para hacer MITM a usuarios iraníes de Gmail.
  • Symantec (2017): mala emisión crónica; Google y Mozilla dejaron de confiar en los certificados de la CA.
  • Varias CAs corporativas: las empresas a veces instalan sus propias CAs raíz en dispositivos gestionados para hacer MITM al tráfico de empleados por monitoreo de seguridad.

Los logs de Certificate Transparency (CT) hacen más detectable la emisión de certs fraudulentos pero no la previenen en tiempo real.

Secuestro de BGP

El protocolo de ruteo de internet (BGP) deja que los ISPs y las redes grandes anuncien qué bloques de IP manejan. Si una red maliciosa o comprometida anuncia rutas para IPs que no posee, el tráfico destinado a esas IPs se redirige por ellas. Usado en ataques reales contra servicios de criptomonedas (varios incidentes 2014-2018).

Las defensas del usuario final contra los secuestros de BGP son limitadas; mayormente esto es un problema de infraestructura de internet. Un VPN puede ayudar marginalmente ruteando por un camino de red distinto.

Contra qué protege HTTPS

HTTPS, cuando está bien implementado y validado, evita que los atacantes:

  • Lean el contenido de tu tráfico cifrado.
  • Modifiquen el contenido en tránsito.
  • Suplanten el servidor de destino (asumiendo que el sistema de CAs no está comprometido).

HTTPS NO evita:

  • La observación de metadatos (SNI, DNS, IP).
  • El análisis de tráfico (timing, tamaño, patrón).
  • Ataques que explotan el compromiso de una CA.
  • Phishing vía dominios parecidos.

Dónde aporta valor un VPN

  1. Cierra la capa de metadatos. El ARP/DNS spoofing en la red local no puede ver tus destinos porque están cifrados en el túnel.
  2. Sortea a los atacantes de la red local. El túnel VPN termina en el servidor del proveedor, no en el AP local fraudulento. Los ataques ARP/DNS en la red local no pueden ver dentro del túnel.
  3. Camino de red distinto. Si tu tráfico transita una ruta BGP comprometida, el punto de salida del VPN puede usar un camino distinto.
  4. Reduce la exposición de SNI. Tu SNI en la conexión VPN es solo "la red de ClownVPN", no el destino real.

Un VPN NO evita:

  • Ataques a tu dispositivo de endpoint (malware, keyloggers).
  • Compromiso de CA en la capa de aplicación.
  • MITM en el propio proveedor VPN (por lo que importa la confianza en el proveedor).

Capas defensivas

Una defensa sólida en 2026 se ve así:

  1. HTTPS en todas partes — extensiones de navegador o comportamiento integrado del navegador que prefiere HTTPS.
  2. VPN en redes no confiables — WiFi público, de hotel, de congreso, siempre que no confíes en la red local.
  3. Actualizaciones de SO y navegador — los parches cierran vulnerabilidades adyacentes al MITM.
  4. Atención a los errores de cert — cuando tu navegador avisa de un certificado, tómatelo en serio.
  5. No uses puertos USB públicos para cargar — el juice jacking es el MITM de la capa física.

Lectura relacionada

🎪 Preguntas frecuentes

¿Cada cuánto pasan de verdad los ataques MITM?
Menos a menudo de lo que insinúa el marketing VPN dramático, pero no raramente. El MITM oportunista (snifar WiFi cercano para cosechar credenciales) pasa de forma rutinaria en entornos abarrotados con objetivos de oportunidad — aeropuertos, congresos, hoteles. El MITM dirigido (ir específicamente a por un individuo conocido) es más raro pero más preocupante cuando pasa. El MITM de nivel gobierno (correr Autoridades de Certificación fraudulentas, explotar vulnerabilidades de redes celulares) es real pero limitado a modelos de amenaza específicos.
Si HTTPS previene el MITM, ¿para qué necesito un VPN?
HTTPS previene el MITM en la capa de contenido pero filtra metadatos (qué hostnames visitas, cuándo, cuántos datos). Un VPN cierra la capa de metadatos. Además, HTTPS depende de la validación correcta de certificados — que mayormente funciona pero ha tenido fallos históricos (DigiNotar 2011, Symantec 2017, certs caducados que los navegadores toleran, certificados mal emitidos). El VPN añade una capa que no depende de que el ecosistema de CAs se porte bien.
¿Un VPN puede hacer él mismo un MITM?
Técnicamente sí, en el sentido de que el proveedor VPN ve tu tráfico en la salida del túnel y podría en principio interceptarlo. Por eso importa la confianza en el proveedor VPN. Los proveedores con reputación (Mullvad, IVPN, ProtonVPN, nosotros) usan arquitecturas no-log y se someten a auditorías independientes para hacer el MITM-por-proveedor lo más improbable posible. Los VPN gratis turbios son absolutamente capaces de esto y a unos cuantos los han pillado haciéndolo (Hola en 2015, el caso Onavo de Facebook, etc.).
¿HSTS protege contra el SSL stripping?
Mayormente sí para sitios de primera. HSTS (HTTP Strict Transport Security) le dice a los navegadores 'usa siempre HTTPS para este dominio'. Una vez has visitado un sitio con HSTS, tu navegador se niega a bajar a HTTP. Los sitios grandes (bancos, Google, GitHub, etc.) también están en la lista de preload de HSTS, lo que significa que tu navegador sabe forzar HTTPS para ellos incluso en la primera visita. Los sitios más pequeños sin HSTS ni preload aún pueden ser strippeados en una conexión de primera visita.
¿Los 'cables públicos de carga gratis' son un riesgo de MITM?
Sí — 'juice jacking'. Un cable USB maliciosamente modificado o un puerto USB público puede establecer una conexión de datos con tu dispositivo y potencialmente exfiltrar datos o instalar malware. Mitigaciones: usa tu propio cable y un adaptador USB solo-energía (un 'condón USB'), activa la restricción de datos USB en los ajustes de tu móvil (Ajustes → Preferencias USB → 'Solo cargar'), o lleva tu propia batería externa. El MITM aquí no es de red pero el principio es el mismo — un intermediario hostil entre tú y tu destino.

🎪 Tuneliza

Cifrado + privacidad de metadatos + camino de red distinto. Gratis.

🤖 Descargar la app gratis