Por qué una clave OpenVPN más grande no elimina el temporizador de renovación

Elegir AES-256 o una clave más larga no dice nada sobre cuánto tiempo se puede usar esa clave. La fortaleza de la clave describe el algoritmo; la política de renovación decide cuándo la sesión deriva material de clave nuevo. Un despliegue puede elegir el cifrado más fuerte disponible y aun así equivocarse con la renovación, porque las dos decisiones se toman en lugares distintos. Confundirlas produce un cambio de cifrado innecesario o una sesión que sobrevive en silencio a su política.

Lea la configuración de renovación antes de tocar el cifrado, y lea ambos extremos cuando lo haga.

La fortaleza de la clave y la vida útil de la clave responden preguntas distintas

El cifrado y el tamaño de la clave limitan cuán caro sería un ataque al tráfico capturado. El intervalo de renovación limita cuánto tráfico protege una clave y cuánto tiempo una clave comprometida sigue siendo útil. Son controles independientes, y un cifrado más fuerte no alarga la vida segura de una sesión. La mayoría de las guías que dicen 'use AES-256' callan sobre la renovación, porque renovar es una cuestión de política y no una elección de algoritmo.

Anote ambas cosas en las notas de despliegue: qué protege el canal de datos y qué dispara la sustitución de sus claves.

La renovación tiene tres disparadores, y cualquiera de los dos extremos puede activarlos

OpenVPN 2.6 documenta disparadores separados para la renegociación basados en bytes, paquetes y tiempo transcurrido. El disparador de tiempo es el que la mayoría de los despliegues dejan por defecto, lo que significa que un túnel silencioso igualmente renueva según lo previsto. Cualquiera de los extremos puede iniciar el intercambio, y el extremo que no lo inició lo sigue. Por eso cambiar el temporizador en un lado no fija el comportamiento de la sesión; el valor efectivo es el del lado que inicia primero.

Los disparadores por bytes y paquetes importan en cargas de alto rendimiento o de paquetes pequeños, donde una política solo por tiempo dejaría que una clave protegiera muchos más datos de los previstos. Si esos contadores quedan desactivados, dígalo deliberadamente en las notas en lugar de dejar el valor por defecto sin examinar.

Una renovación expone el flujo de autenticación

Una renegociación es un nuevo handshake TLS, lo que significa que la ruta de autenticación se ejecuta otra vez. Los despliegues con códigos de un solo uso, tokens de hardware o un desafío RADIUS lo descubren de la manera difícil: la primera conexión funciona y la sesión muere una hora después, cuando el segundo handshake pide un código que ya se usó. auth-gen-token existe para salvar esa brecha permitiendo que el servidor emita un token de corta duración para la renegociación en lugar de exigir un nuevo inicio de sesión interactivo.

Trátelo como un problema de flujo de trabajo que hay que resolver con el operador, no como prueba de que la renovación deba desactivarse.

Pruebe la renovación bajo carga, no en una sesión de un minuto

Una prueba de aceptación que conecta, hace un ping una vez y se desconecta nunca llega a la renovación. Ejecute una sesión lo bastante larga para cruzar el disparador configurado, mantenga una transferencia en marcha durante toda ella y vigile los registros de ambos extremos para ver el nuevo handshake. Luego pruebe la ruta de fallo: qué hace el cliente si la renegociación no puede completarse. Un túnel que cae limpiamente es más fácil de diagnosticar que uno que sigue enviando hacia una sesión muerta.

No lea una transferencia grande exitosa como prueba de un umbral criptográfico. Solo muestra que la ruta y los contadores soportaron ese volumen de tráfico.

Documente ambas decisiones

El registro necesita dos líneas: cómo se protegen los paquetes y cuándo se sustituye esa protección. Añada la autoridad de cada valor, porque el cifrado puede venir de un valor por defecto de la distribución mientras que el temporizador viene de una política interna. Un operador futuro no debería tener que inferir ninguno de los dos desde un archivo de configuración.

Si la compatibilidad obliga a una excepción, delimítela a una versión y a una fecha de fin. Una excepción que sobrevive a su razón se convierte en la política que nadie recuerda haber elegido.