Qué es un ataque man-in-the-middle

Un ataque man-in-the-middle (MITM) es cuando un atacante se posiciona entre dos partes que se comunican sobre una red, leyendo o modificando tráfico en ambas direcciones sin que ninguna de las partes se de cuenta de que no están hablando entre sí directamente.

Imagina: conectas al sitio web de tu banco. Un atacante ha comprometido la red intermedia. Interceptan tu conexión, presentan su propio certificado (pretendiendo ser el banco), y reenvían tu tráfico al banco real — recolectando contraseñas o modificando transacciones en el camino.

Si TLS funciona correctamente, el certificado del atacante falla la validación y tu navegador te advierte. Si TLS funciona incorrectamente, no te das cuenta.

Dónde suceden los ataques MITM

Algunos escenarios donde esto es realista:

• Wi-Fi público. Redes de hotel, Wi-Fi de café, redes de aeropuerto. El atacante puede ser el operador de la red o cualquier otra persona en la misma red. Ver VPN para Wi-Fi público sobre por qué importa.
• Routers comprometidos. Routers caseros con contraseñas por defecto, routers provistos por el ISP con backdoors. El atacante controla tu gateway; todo pasa por ellos.
• Adversarios a nivel estatal. Algunos países operan MITM a escala vía autoridades de certificación falsas emitidas desde CAs obligadas. Menos común desde que Certificate Transparency hizo visible la mala emisión, pero no se ha ido.
• CAs comprometidas. La clave intermedia de una CA es robada; los atacantes emiten certs que parecen válidos para dominios arbitrarios. Ha pasado (DigiNotar, Comodo). Los navegadores eventualmente desconfían de la CA afectada.

Cómo TLS defiende contra MITM

TLS verifica la identidad del servidor a través de certificados firmados por CAs confiables. Cuando conectas, el servidor presenta su certificado. Tu navegador chequea: ¿este certificado está firmado por una CA en la que confío? ¿El hostname coincide? ¿Ha sido revocado?

Si cualquier chequeo falla, el navegador rehúsa conectar o te advierte. Si todo pasa, la sesión cifrada continúa.

Para que esto defienda contra MITM, tres cosas deben sostenerse:

1. El sistema de CAs debe estar incomprometido. Una CA maliciosa puede emitir certs válidos para cualquier dominio.
2. Tu almacén de confianza debe estar limpio. Si un atacante instaló su cert de CA en tu máquina (redes corporativas, malware), pueden emitir certs válidos en los que confiarás.
3. Tienes que respetar la advertencia. Los navegadores advierten en errores de cert; los usuarios siguen adelante de todas formas.

Certificate pinning: defensa más fuerte

Para conexiones de alto valor, la validación regular de CA no es suficiente. El certificate pinning hardcodea qué certificado específico (o CA) un cliente debería esperar. Si el certificado no coincide con el pin, la conexión falla — aun si está firmado por una CA "confiable".

Fexyn pinnea su propia CA intermedia en el cliente desktop. El cliente rehúsa cualquier conexión VPN donde el cert del servidor no esté firmado por esa intermedia. Una CA pública comprometida no puede ser usada para hacer MITM al tráfico Fexyn — el cliente no confía en CAs públicas para conexiones VPN, solo en la PKI interna de Fexyn.

Esta es una de las razones por las que los ataques MITM contra Fexyn requieren comprometer específicamente la infraestructura de firma de Fexyn, no solo cualquier CA aleatoria en internet.

Lo que una VPN hace y no hace

Una VPN hace MITM en la red subyacente mayormente imposible. El túnel está cifrado entre tu dispositivo y el servidor VPN; nadie en el camino puede hacer MITM a lo que está adentro.

Una VPN no protege contra MITM en el destino — una vez que tu tráfico sale del servidor VPN y va a su objetivo real, TLS normal es la única defensa. Y una VPN no protege contra MITM en el origen — malware en tu dispositivo puede hacerte MITM antes de que el tráfico entre al túnel.

Lee más en la vista general de seguridad y la guía de Wi-Fi público.

El intento de MITM a nivel estatal más documentado en el contexto VPN es el push del root CA Qaznet de Kazajistán en 2015 y 2019, que habría habilitado la intercepción HTTPS al por mayor si los principales fabricantes de navegadores no lo hubieran puesto en lista de bloqueo. La guía VPN para Kazajistán cubre el modelo de amenaza y qué protocolo es estructuralmente inmune a él.

Prueba Fexyn gratis por 7 días.