Registro de OpenVPN: cifrado del canal de control frente al cifrado del canal de datos

Una línea de registro que nombra DHE-RSA-AES256-SHA no es un resumen de toda la conexión. Pertenece al handshake TLS que protege el canal de control, y el tráfico dentro del túnel puede cifrarse con algo completamente distinto. Presentarla como el cifrado de datos de la VPN es el error que hay que evitar.

Importan dos resultados, y responden a preguntas distintas. Uno es la suite TLS negociada para el canal de control; el otro es el cifrado de datos de los paquetes que transporta el túnel.

Dos resultados, dos preguntas

El canal de control transporta el handshake y los mensajes de gestión entre los pares. Su cifrado lo elige la pila TLS, así que el nombre sigue las convenciones TLS. El canal de datos transporta el tráfico de usuario y lo configura la propia negociación de cifrado de OpenVPN.

Decide qué pregunta respondes antes de leer cualquiera de las dos líneas. Que el túnel esté cifrado y que el handshake sea fuerte no son la misma pregunta.

Un extracto de registro que muestre ambas líneas es el útil. Lee la línea de control para la versión y la suite TLS, y la línea de datos para el algoritmo que protege realmente la carga útil.

Descifra el nombre de la suite TLS en su propio contexto

En un nombre histórico al estilo OpenSSL como DHE-RSA-AES256-SHA, cada componente describe una decisión distinta. DHE es el acuerdo de claves Diffie-Hellman efímero, RSA es el método de autenticación, AES256 es AES-256 en modo CBC para los registros TLS, y SHA es el MAC de registro basado en SHA-1.

El último componente no es una huella del certificado, y leerlo como tal es un error común. El nombre tampoco indica por sí solo la versión del protocolo, porque TLS 1.3 usa un esquema de nombres completamente distinto. TLS_AES_256_GCM_SHA384 sigue esa forma más reciente, en la que el hash final forma parte de la construcción de la suite y no es una elección de MAC. Aplica la lectura por componentes solo al estilo de nombres más antiguo.

La referencia de suites de OpenSSL asocia estos nombres con sus definiciones si algún componente no resulta familiar.

Lee el resultado del canal de datos para el tráfico transportado

Para el tráfico transportado, lee la línea del canal de datos de la misma sesión. Una lista data-ciphers en la configuración es un conjunto permitido, no la prueba de que se haya negociado un algoritmo concreto. El registro anota la elección; la configuración enumera el menú.

Un cifrado AEAD como AES-GCM lleva su propia comprobación de integridad, así que un HMAC aparte para el canal de datos no forma parte de esa ruta.

La directiva auth no mejora TLS, ni los certificados, ni el cifrado de datos. Selecciona un resumen para las partes del protocolo que aún usan uno, y con un cifrado de datos AEAD no hay un HMAC de datos aparte que configurar.

Mantén las comprobaciones de identidad fuera del resultado del cifrado

El algoritmo de firma del certificado, la validación de la cadena de confianza y la verificación del nombre del par son tres propiedades más de las que un nombre de cifrado no dice nada. Un certificado caducado falla, por fuerte que sea la suite. Un nombre de servidor que no coincide falla igual. Corregir un ajuste de resumen en el perfil no repara ninguna de las dos cosas.

Mantén esas comprobaciones en las notas de revisión junto al resultado del cifrado, sin fundirlas con él.

Anota los resultados negociados de la sesión actual

Toma los resultados de la conexión actual y anota junto a ellos las versiones del cliente y del servidor. Un registro de solo añadir puede contener la línea de una sesión anterior, y citarla como actual es la forma en que un problema corregido parece persistir.

Para una revisión de políticas, entrega al responsable de la configuración la versión y la suite TLS negociadas, el cifrado de datos elegido y los ajustes de validación de certificados juntos. Modifica esa capa y luego lee un registro nuevo para confirmar los nuevos valores negociados.