¿Protege una VPN contra KRACK? Qué corrige el parche

Si compras una VPN porque un titular decía que KRACK rompe el cifrado de Wi-Fi, estás reparando la capa equivocada. Aquella revelación de 2017 describía una familia de ataques de reinstalación de claves contra el handshake de cuatro vías de WPA2, y la reparación llegó como actualizaciones del sistema operativo, parches de controladores inalámbricos y firmware de routers. Un túnel puede ocultar tu tráfico de la red local, pero no puede reparar un handshake que termina por debajo de él. Así que la primera pregunta no es qué VPN comprar; es cuál de tus dispositivos sigue ejecutando una pila inalámbrica sin parchear.

La misma distinción responde a la preocupación por el presupuesto. Quien no puede permitirse una suscripción nunca quedó excluido del remedio real, porque el remedio era una actualización gratuita. Lo que cuesta dinero es sustituir hardware que ya no recibe ninguna.

Qué manipuló realmente el ataque

WPA2 deriva una clave por pareja nueva en el momento de la asociación mediante un handshake de cuatro vías. El punto de acceso envía un nonce, el cliente responde con el suyo, ambas partes calculan la clave transitoria por pareja y el punto de acceso confirma con un mensaje que el cliente acusa recibo. Un ataque de reinstalación de claves interfiere en esa secuencia en lugar de adivinar la frase de contraseña, y obliga a un cliente a instalar una clave que ya había instalado. Cada reinstalación puede reiniciar el nonce de transmisión y el contador de repetición de recepción ligados a esa clave.

Cuando esos contadores retroceden, parte del tráfico que debería haberse rechazado vuelve a ser aceptable. Según la variante y la implementación, un atacante dentro del alcance de radio podía reproducir tramas, descifrarlas o inyectarlas. El handshake de clave de grupo y el de transición rápida tenían sus propias variantes, y por eso el aviso enumeraba varios nombres de ataque en lugar de uno.

Android 6.0 y posteriores fue el peor caso. Sus versiones de wpa_supplicant podían ser forzadas a instalar una clave de todo ceros, lo que hacía el descifrado mucho más fácil que en plataformas donde la reinstalación solo reiniciaba contadores. Ese detalle separó una debilidad teórica de una práctica en la plataforma de teléfono más común de la época.

La corrección vive en la pila inalámbrica

La corrección original dijo a los supplicants y a los puntos de acceso que ignoraran un mensaje de handshake retransmitido una vez que la clave ya estaba instalada. Las compilaciones parcheadas de wpa_supplicant y hostapd la llevaban, y las distribuciones la retrasladaron a ramas antiguas, así que la cadena que imprime wpa_supplicant -v es un punto de partida y no un veredicto. Lee el aviso de seguridad de la distribución y confirma el parche concreto, no solo el número de versión. Una compilación que declara una versión antigua puede estar corregida, y una que declara una nueva puede seguir sin un parche del fabricante.

Los dos extremos del enlace necesitan atención. Un router reparado no parchea el portátil que se asocia con él, y un portátil reparado no parchea el router. Los fabricantes publicaban avisos por producto, y las correcciones de router solían ir por detrás de las actualizaciones de teléfono porque cada modelo necesita su propia compilación de firmware. Si la última versión de un dispositivo es anterior al aviso, trátalo como no parcheado hasta que el fabricante diga lo contrario.

Para el equipo que no puedes actualizar, las opciones son estrechas y poco glamurosas. Retíralo, mantenlo fuera de redes que lleven tráfico sensible, o confínalo a un segmento donde sus únicos pares sean igual de prescindibles. Ninguna de esas opciones implica una suscripción, y ninguna mejora eligiendo otro proveedor de túnel.

Qué cubre un túnel

Una VPN mueve la frontera. Tu dispositivo cifra cada paquete y lo envía a un servidor VPN, que lo descifra y lo reenvía. Quien manipula el enlace Wi-Fi ve paquetes externos del túnel, no la carga útil de dentro, así que un ataque de reinstalación que expone tramas de la capa de enlace no expone automáticamente el contenido de la conexión tunelizada. Esa protección se mantiene incluso mientras la pila inalámbrica de debajo sigue siendo vulnerable, y es exactamente por eso que los dos controles se confunden.

El matiz es «tunelizado». El túnel dividido, una lista de omisión o una excepción de portal cautivo envían parte del tráfico fuera del túnel, y ese tráfico no obtiene ningún beneficio de él. También ocurre con el tráfico de otros dispositivos de la misma red que nunca instalaron el cliente. Un túnel es una decisión por dispositivo y por ruta, no una propiedad de la sala, y una VPN a nivel de router solo cubre lo que realmente pasa por el router.

Lo que el túnel no puede hacer es reparar el controlador, detener una inundación de desautenticación o impedir que un atacante interfiera el canal. Tampoco puede proteger una conexión que nunca entra en él. Son problemas de disponibilidad y de capa de enlace, y se quedan con la pila inalámbrica por fuerte que sea el conjunto de cifrados del túnel.

HTTPS y el túnel protegen saltos distintos

Una sola carga de página puede implicar tres protecciones separadas: el enlace Wi-Fi, el túnel al servidor VPN y la sesión TLS al sitio web. Cada una se negocia de forma independiente. TLS con un certificado válido y una versión de protocolo moderna te da cifrado autenticado entre navegador y sitio incluso cuando el primer salto es hostil, porque la comprobación del certificado es lo que impide que un impostor sustituya su propia clave.

Esa comprobación tiene puntos débiles en los bordes. Una redirección de HTTPS a HTTP, una página que carga scripts por HTTP simple o un usuario que hace clic a través de un aviso de certificado sacan tráfico de la sesión protegida. HSTS y las páginas intermedias del navegador existen porque esos errores son frecuentes, no porque TLS sea frágil.

Mantener HTTPS y un túnel no hace que la implementación inalámbrica deje de ser vulnerable. Las tramas siguen siendo descifradas por un controlador defectuoso; la diferencia es qué encuentra el atacante dentro y si ese contenido ya estaba protegido por otra cosa.

Orden de reparación para una red mixta

Empieza por el punto de acceso, porque es el dispositivo que controlas y del que depende cada cliente. Luego recorre los sistemas operativos de los clientes, de los más antiguos a los más nuevos, ya que las plataformas que dejaron de recibir actualizaciones son las que nunca se parchearán. Solo cuando ese inventario esté hecho tiene sentido una decisión sobre la VPN, y es una decisión sobre exposición, no sobre reparación. Hacerlo al revés, primero el túnel y luego el firmware, deja el defecto real en su sitio mientras dure la suscripción.

Anota qué verificaste, incluida la versión de firmware y la fecha. «Actualizado» no es un estado que nadie pueda auditar después.

Tres comprobaciones cubren la mayor parte del trabajo, y van en este orden. No te saltes la tercera solo porque las dos primeras salieron limpias.

• Firmware del router: compara la versión instalada con la página de avisos del fabricante, no con el botón de actualización.
• SO del cliente: confirma el nivel de parches que incluye la corrección inalámbrica para cada teléfono, portátil y tableta.
• Restos: enumera los dispositivos sin ruta de parche y decide retirar, aislar o aceptar.

Si la lista de restos es larga, una red de invitados con aislamiento de clientes gana tiempo mientras se sustituye el hardware. Luego prueba un cliente conocido en cada banda, anota el resultado y vuelve a comprobar tras la siguiente versión de firmware. El inventario de hardware es lo que hace rápido el próximo aviso; el túnel es lo que cubre el hueco mientras tanto.