Pourquoi une clé OpenVPN plus longue ne supprime pas le minuteur de renouvellement

Choisir AES-256 ou une clé plus longue ne dit rien sur la durée pendant laquelle cette clé peut être utilisée. La force de la clé décrit l'algorithme; la politique de renouvellement décide quand la session dérive de nouveaux éléments de clé. Un déploiement peut choisir le chiffrement le plus fort disponible et se tromper tout de même sur le renouvellement, car les deux décisions sont prises à des endroits différents. Les confondre produit soit un changement de chiffrement inutile, soit une session qui survit silencieusement à sa politique.

Lisez les réglages de renouvellement avant de toucher au chiffrement, et lisez les deux pairs quand vous le faites.

La force de la clé et la durée de vie de la clé répondent à des questions différentes

Le chiffrement et la taille de clé bornent le coût d'une attaque sur le trafic capturé. L'intervalle de renouvellement borne la quantité de trafic qu'une clé protège et la durée pendant laquelle une clé compromise reste utile. Ce sont des réglages indépendants, et un chiffrement plus fort n'allonge pas la durée de vie sûre d'une session. La plupart des guides qui disent « utilisez AES-256 » restent muets sur le renouvellement, car le renouvellement est une question de politique et non un choix d'algorithme.

Consignez les deux dans les notes de déploiement : ce qui protège le canal de données, et ce qui déclenche le remplacement de ses clés.

Le renouvellement a trois déclencheurs, et chaque pair peut les activer

OpenVPN 2.6 documente des déclencheurs distincts pour la renégociation selon les octets, les paquets et le temps écoulé. Le déclencheur temporel est celui que la plupart des déploiements laissent par défaut, ce qui signifie qu'un tunnel silencieux renouvelle quand même selon le calendrier. Chaque pair peut lancer l'échange, et le pair qui ne l'a pas initié suit. Changer le minuteur d'un côté ne fixe donc pas le comportement de la session ; la valeur effective est celle du côté qui initie en premier.

Les déclencheurs par octets et par paquets comptent pour les charges à haut débit ou à petits paquets, où une politique fondée uniquement sur le temps laisserait une clé protéger bien plus de données que prévu. Si ces compteurs restent désactivés, dites-le délibérément dans les notes plutôt que de laisser la valeur par défaut sans examen.

Un renouvellement expose le parcours d'authentification

Une renégociation est une nouvelle poignée de main TLS, ce qui signifie que le chemin d'authentification s'exécute de nouveau. Les déploiements qui utilisent des codes à usage unique, des jetons matériels ou un défi RADIUS le découvrent à leurs dépens : la première connexion fonctionne et la session meurt une heure plus tard, quand la seconde poignée de main demande un code déjà utilisé. auth-gen-token existe pour combler cet écart en permettant au serveur d'émettre un jeton de courte durée pour la renégociation au lieu d'exiger une nouvelle connexion interactive.

Traitez cela comme un problème de flux de travail à résoudre avec l'exploitant, non comme la preuve qu'il faut désactiver le renouvellement.

Testez le renouvellement sous charge, pas dans une session d'une minute

Un test d'acceptation qui se connecte, fait un ping et se déconnecte n'atteint jamais le renouvellement. Lancez une session assez longue pour franchir le déclencheur configuré, maintenez un transfert en cours pendant toute sa durée et surveillez les journaux des deux pairs pour la nouvelle poignée de main. Testez ensuite le chemin d'échec : ce que fait le client si la renégociation ne peut pas aboutir. Un tunnel qui tombe proprement est plus facile à diagnostiquer qu'un tunnel qui continue d'envoyer dans une session morte.

Ne lisez pas un gros transfert réussi comme la preuve d'un seuil cryptographique. Il montre seulement que le chemin et les compteurs ont supporté ce volume de trafic.

Documentez les deux choix

L'enregistrement a besoin de deux lignes : comment les paquets sont protégés, et quand cette protection est remplacée. Ajoutez l'autorité de chaque valeur, car le chiffrement peut venir d'un défaut de distribution tandis que le minuteur vient d'une politique interne. Un futur exploitant ne devrait pas avoir à déduire l'un ou l'autre d'un fichier de configuration.

Si la compatibilité impose une exception, limitez-la à une version et à une date de fin. Une exception qui survit à sa raison devient la politique dont personne ne se souvient de l'avoir choisie.