Definición (ficha de glosario): tls-crypt-v2 es el modo de cifrado de canal de control específico por cliente de OpenVPN. Cada cliente recibe una clave tls-crypt única (Kc) más una copia encapsulada de esa clave (WKc) cifrada con una clave de servidor compartida. Al conectar, el cliente envía WKc dentro de un P_CONTROL_HARD_RESET_CLIENT_V3 paquete; el servidor desencapsula Kc y ambos pares cifran entonces los paquetes del canal de control con la clave específica del cliente en lugar de una única clave precompartida de grupo.

Diagram comparing pre-shared key VPN authentication concepts
Fuente: Wikimedia Commons — Lbutrico clave precompartida

Cuando una pantalla de ajustes de OpenVPN o las FAQ de un proveedor mencionan “tls-crypt-v2”, se refieren a un mecanismo de protección del canal de control, no a un cifrado de canal de datos ni a un protocolo VPN independiente. Entender la diferencia importa para flotas grandes y proveedores de VPN alojada: el clásico --tls-auth and --tls-crypt comparten una clave de grupo entre todos los clientes y servidores. Si cualquier par se ve comprometido, esa clave compartida deja de ofrecer una protección significativa frente a DoS y de la pila TLS para todos los demás. tls-crypt-v2 mantiene compartida la clave de encapsulado del servidor y da a cada cliente su propia Kc.

De dónde proviene el diseño

OpenVPN documenta la función en doc/tls-crypt-v2.txt y en la documentación de API generada del proyecto para cifrado del canal de control (tls-crypt, tls-crypt-v2). El mismo esquema específico del cliente aparece en el borrador OpenVPN Wire Protocol bajo «Client-specific encryption keys», que señala explícitamente que las implementaciones existentes denominan la función tls-crypt-v2.

La justificación es tanto operativa como criptográfica. Las claves de grupo compartidas caducan más rápido a medida que aumenta el número de clientes, y un portátil filtrado puede forzar una rekey masiva. Al cifrar el Kc de cada cliente bajo una clave de servidor y enviar el WKc con el cliente, los operadores pueden revocar o rotar clientes individuales sin redistribuir una única clave estática de toda la comunidad. Los servidores aún pueden aceptar tls-crypt or tls-auth clientes durante la migración porque el opcode de hard-reset V3 señala el nuevo modo.

SSL VPN topology showing client, network, and server roles
Fuente: Wikimedia Commons — Topología de VPN SSL

A alto nivel, el flujo es una cookie cifrada:

  1. Los operadores crean una tls-crypt-v2 servidor clave usada solo para envolver y desenvolver las claves de cliente.
  2. Para cada cliente generan una Kc nueva, la envuelven como WKc con la clave del servidor y entregan Kc || WKc al cliente (a menudo como un bloque PEM encabezado BEGIN OpenVPN tls-crypt-v2 client key).
  3. El primer paquete de control del cliente usa el opcode P_CONTROL_HARD_RESET_CLIENT_V3 y transporta WKc.
  4. El servidor descifra WKc, carga Kc, opcionalmente ejecuta un tls-crypt-v2-verify script contra los metadatos y, a partir de entonces, ambas partes usan Kc para la protección del canal de control al estilo tls-crypt.

Los metadatos opcionales dentro del blob encapsulado pueden transportar comprobaciones de política tempranas (por ejemplo, indicios de identidad del cliente) para que un servidor pueda abortar handshakes abusivos antes de invertir trabajo TLS costoso. Esa cancelación temprana es una de las razones por las que la función se comercializa por su resistencia a DoS en sistemas grandes multiinquilino. Los grandes proveedores de VPN se benefician especialmente porque los endpoints de clientes comprometidos ya no exponen automáticamente una única clave de grupo tls-crypt compartida de la que depende el resto de clientes para el filtrado del canal de control.

Qué protege tls-crypt-v2 — y qué no

tls-crypt-v2 cifra y autentica canal de control paquetes: el tráfico del handshake TLS que negocia las claves de sesión y las opciones. No sustituye el cifrado del canal de datos (AES-GCM, ChaCha20-Poly1305, etc.), no elige las IP de salida y no implementa una política de no-logs. Piénsalo como una armadura alrededor del plano de control de OpenVPN para que el ruido UDP no autenticado y las claves de grupo robadas sean menos útiles contra la pila TLS.

Las notas de la versión de OpenVPN 2.7.8 (resumidas por Linux Compatible el 7 de octubre de 2026) también muestran por qué la robustez en torno a tls-crypt-v2 sigue importando: una corrección de 2.7.8 evitó que los clientes confiaran ciegamente en una solicitud del par para reenviar una clave de cliente encapsulada cuando no había material de clave disponible. La política CRA de Italia trató esa clase de problema de «un servidor malicioso puede interrumpir el cliente» como degradación de la robustez y no como una ruptura de confidencialidad digna de CVE, pero los operadores siguen queriendo el parche en todos los clientes que hablan tls-crypt-v2.

En qué se diferencia de tls-auth y tls-crypt

  • tls-auth: Integridad solo HMAC en los paquetes de control con una clave estática compartida; no cifra el canal de control.
  • tls-crypt: Cifra y autentica los paquetes de control con una clave de grupo compartida.
  • tls-crypt-v2: Misma protección de estilo AEAD del canal de control que tls-crypt, pero con Kc por cliente más cookies WKc envueltas por el servidor.

Los tres se refieren al canal de control. Confundirlos con el handshake Noise de WireGuard o con IKEv2 es un error de glosario habitual. WireGuard no usa tls-crypt-v2; los usuarios de OpenVPN que habilitan WireGuard en otro lugar están en una pila completamente distinta. Del mismo modo, habilitar tls-crypt-v2 no actualiza por arte de magia cifrados obsoletos del canal de datos ni corrige fugas de DNS fuera del túnel.

Lista de comprobación práctica

  1. Si operas un servidor OpenVPN multicliente o una flota de un proveedor VPN, prefiere tls-crypt-v2 a una única clave tls-crypt compartida para que un cliente perdido no envenene toda la clave de grupo.
  2. Mantén la clave de encapsulado del servidor con respaldo sin conexión y rotación posible; planifica cómo se reemiten los archivos WKc cuando cambia esa clave del servidor.
  3. Confirma que los clientes realmente hablan V3 hard-reset (compilaciones modernas de OpenVPN) antes de desactivar tls-auth/tls-crypt heredados en el servidor.
  4. Sigue OpenVPN 2.7.8+ por las correcciones de robustez de tls-crypt-v2 aunque un cambio no tenga un ID de CVE.
  5. Recuerda: un encapsulado fuerte del canal de control no puede corregir una contraseña de usuario reutilizada, un portal de phishing o una fuga de DNS fuera del túnel.

En resumen: tls-crypt-v2 es la respuesta de OpenVPN a «¿cómo mantienen los despliegues grandes el cifrado del canal de control sin una clave estática compartida catastrófica?». Aprende el modelo de cookies, mantén separadas las preguntas del canal de datos y de políticas, y trata la higiene de claves por cliente como parte de las operaciones VPN habituales, no como una opción exótica solo para empresas.