Définition (fiche de glossaire) : tls-crypt-v2 est le mode de chiffrement du canal de contrôle spécifique au client d’OpenVPN. Chaque client reçoit une clé tls-crypt unique (Kc) ainsi qu’une copie encapsulée de cette clé (WKc) chiffrée avec une clé serveur partagée. Lors de la connexion, le client envoie WKc à l’intérieur d’un P_CONTROL_HARD_RESET_CLIENT_V3 paquet ; le serveur désencapsule Kc, puis les deux pairs chiffrent les paquets du canal de contrôle avec la clé spécifique au client plutôt qu’avec une clé pré-partagée de groupe.

Diagram comparing pre-shared key VPN authentication concepts
Source : Wikimedia Commons — Lbutrico clé pré-partagée

Lorsqu’un écran de paramètres OpenVPN ou la FAQ d’un fournisseur mentionne « tls-crypt-v2 », cela désigne un mécanisme de protection du canal de contrôle, et non un chiffrement du canal de données ni un protocole VPN autonome. Comprendre cette différence est important pour les grands parcs et les fournisseurs VPN hébergés : classiques --tls-auth and --tls-crypt partagent une même clé de groupe entre tous les clients et serveurs. Si un pair est compromis, cette clé partagée cesse d’offrir une protection DoS et de pile TLS pertinente pour tous les autres. tls-crypt-v2 conserve la clé d’encapsulation côté serveur en partage, tout en donnant à chaque client sa propre Kc.

D’où vient cette conception

OpenVPN documente cette fonctionnalité dans doc/tls-crypt-v2.txt et dans la documentation API générée du projet pour chiffrement du canal de contrôle (tls-crypt, tls-crypt-v2). Le même schéma spécifique au client apparaît dans le brouillon OpenVPN Wire Protocol sous « Clés de chiffrement spécifiques au client », qui note explicitement que les implémentations existantes appellent cette fonctionnalité tls-crypt-v2.

La justification est autant opérationnelle que cryptographique. Les clés de groupe partagées expirent plus vite à mesure que le nombre de clients augmente, et un ordinateur portable compromis peut forcer un renouvellement de clés à grande échelle. En chiffrant le Kc de chaque client sous une clé serveur et en livrant le WKc avec le client, les opérateurs peuvent révoquer ou renouveler des clients individuels sans redistribuer une unique clé statique commune à toute la communauté. Les serveurs peuvent toujours accepter les anciens tls-crypt or tls-auth clients pendant la migration, car l’opcode hard-reset V3 signale le nouveau mode.

SSL VPN topology showing client, network, and server roles
Source : Wikimedia Commons — Topologie SSL VPN

À un niveau élevé, le flux est un cookie chiffré :

  1. Les opérateurs créent une tls-crypt-v2 serveur clé utilisée uniquement pour envelopper et désenvelopper les clés client.
  2. Pour chaque client, ils génèrent une Kc neuve, l'enveloppent en WKc sous la clé serveur, et remettent Kc || WKc au client (souvent sous forme d'un bloc PEM intitulé BEGIN OpenVPN tls-crypt-v2 client key).
  3. Le premier paquet de contrôle du client utilise l'opcode P_CONTROL_HARD_RESET_CLIENT_V3 et transporte WKc.
  4. Le serveur déchiffre WKc, charge Kc, exécute éventuellement un tls-crypt-v2-verify script sur les métadonnées, puis les deux côtés utilisent Kc pour la protection du canal de contrôle de type tls-crypt.

Les métadonnées facultatives contenues dans le blob encapsulé peuvent transporter des contrôles de politique précoces (par exemple des indices d'identité client) afin qu'un serveur puisse interrompre les handshakes abusifs avant d'engager un travail TLS coûteux. Cet abandon précoce est l'une des raisons pour lesquelles la fonctionnalité est présentée comme une protection contre les DoS sur les grands systèmes multi-locataires. Les grands fournisseurs VPN en bénéficient particulièrement, car les points de terminaison clients compromis n'exposent plus automatiquement une clé de groupe tls-crypt unique et partagée dont tous les autres clients dépendent pour le filtrage du canal de contrôle.

Ce que tls-crypt-v2 protège — et ce qu'il ne protège pas

tls-crypt-v2 chiffre et authentifie canal de contrôle paquets : le trafic de la poignée de main TLS qui négocie les clés de session et les options. Il ne remplace pas le chiffrement du canal de données (AES-GCM, ChaCha20-Poly1305, et ainsi de suite), ne choisit pas les IP de sortie et n’implémente pas une politique sans journaux. Considérez-le comme une armure autour du plan de contrôle d’OpenVPN, afin que le bruit UDP non authentifié et les clés de groupe volées soient moins utiles contre la pile TLS.

Les notes de version d’OpenVPN 2.7.8 (résumées par Linux Compatible le 7 octobre 2026) montrent aussi pourquoi la robustesse autour de tls-crypt-v2 reste importante : un correctif de la 2.7.8 a empêché les clients de faire aveuglément confiance à une requête d’un pair demandant de renvoyer une clé client encapsulée alors qu’aucun matériel de clé n’était disponible. La politique CRA de l’Italie a traité cette classe de problèmes « un serveur malveillant peut perturber le client » comme une dégradation de la robustesse plutôt que comme une rupture de confidentialité justifiant un CVE, mais les opérateurs veulent tout de même le correctif sur chaque client qui parle tls-crypt-v2.

En quoi il diffère de tls-auth et tls-crypt

  • tls-auth : Intégrité HMAC uniquement sur les paquets de contrôle avec une clé statique partagée ; ne chiffre pas le canal de contrôle.
  • tls-crypt : Chiffre et authentifie les paquets de contrôle avec une seule clé de groupe partagée.
  • tls-crypt-v2 : Même protection de type AEAD du canal de contrôle que tls-crypt, mais avec une Kc par client plus des cookies WKc encapsulés par le serveur.

Les trois concernent le canal de contrôle. Les confondre avec le handshake Noise de WireGuard ou avec IKEv2 est une erreur de glossaire courante. WireGuard n’utilise pas tls-crypt-v2 ; les utilisateurs d’OpenVPN qui activent WireGuard ailleurs sont sur une pile entièrement différente. De même, activer tls-crypt-v2 ne met pas magiquement à niveau les chiffrements obsolètes du canal de données et ne corrige pas les fuites DNS hors du tunnel.

Liste de contrôle pratique

  1. Si vous exploitez un serveur OpenVPN multi-clients ou une flotte de fournisseur VPN, préférez tls-crypt-v2 à une clé tls-crypt unique partagée afin qu’un client perdu n’empoisonne pas toute la clé de groupe.
  2. Conservez la clé d’encapsulation du serveur sauvegardée hors ligne et renouvelable ; prévoyez comment les fichiers WKc sont réémis lorsque cette clé serveur change.
  3. Confirmez que les clients parlent réellement le hard-reset V3 (builds OpenVPN modernes) avant de désactiver tls-auth/tls-crypt hérités sur le serveur.
  4. Suivez OpenVPN 2.7.8+ pour les correctifs de robustesse de tls-crypt-v2 même lorsqu’un changement n’a pas d’ID CVE.
  5. N’oubliez pas : une encapsulation robuste du canal de contrôle ne corrige ni un mot de passe utilisateur réutilisé, ni un portail de phishing, ni une fuite DNS hors du tunnel.

En bref : tls-crypt-v2 est la réponse d’OpenVPN à « comment les grands déploiements conservent-ils le chiffrement du canal de contrôle sans une clé statique partagée catastrophique ? » Apprenez le modèle de cookies, séparez les questions de canal de données et de politique, et traitez l’hygiène des clés par client comme une partie des opérations VPN normales plutôt que comme une option exotique réservée aux entreprises.