Tracer les paquets de contrôle OpenVPN : tls-auth avant TLS

Une défaillance tls-auth est généralement signalée comme un problème de poignée de main, alors qu’elle ne l’a jamais été. Le HMAC est vérifié sur le paquet de contrôle avant tout traitement TLS, donc une clé ou une direction incorrecte produit une défaillance qui ressemble à un problème de certificat et se décide deux couches plus tôt. Traiter l’enveloppe comme un objet à part entière raccourcit le diagnostic : lisez les champs, confirmez que la vérification se déclenche tôt, puis comparez les trois éléments sur lesquels les deux extrémités doivent s’accorder.

Lisez l’enveloppe dans l’ordre où elle est construite

Un paquet de contrôle transporte un identifiant de session, le HMAC tls-auth facultatif, des informations de rejeu et d’acquittement, et un identifiant de message fiable, puis vient la charge utile du type de message. Quand le message est un message de poignée de main, la charge utile se trouve être du texte chiffré TLS. C’est toute la relation : la matière TLS circule dans un message que l’enveloppe protège déjà. La référence du protocole réseau d’OpenVPN énumère les champs du canal de contrôle dans cet ordre.

La couche de fiabilité se confond facilement avec de la cryptographie. Les acquittements, la retransmission et l’identifiant de message existent pour que les messages de contrôle arrivent une fois et dans l’ordre sur un transport peu fiable. Ce n’est pas de l’authentification, et un identifiant de message correct ne prouve rien sur l’auteur du paquet.

Gardez ce regroupement conceptuel. Ce n’est pas un schéma d’ordre des octets, et cela ne suffit pas à calculer une étiquette, car les champs qui entrent dans le HMAC dépendent de l’implémentation, de la version et du mode.

Montrez que la vérification se déclenche avant la poignée de main

Un récepteur qui détient la clé partagée peut vérifier le HMAC et écarter immédiatement un paquet forgé, sans allouer d’état de poignée de main ni faire de travail de clé publique. La protection couvre aussi les paquets initiaux de poignée de main, et c’est précisément pourquoi une mauvaise clé se manifeste comme une connexion échouée et non comme une erreur d’authentification tardive.

Augmentez la verbosité du démon et surveillez le canal de contrôle plutôt que l’interface tun :

openvpn --config /etc/openvpn/server.conf --verb 6

Ce que vous cherchez, c’est un échec de vérification HMAC du canal de contrôle rapporté au niveau du paquet, avant toute alerte TLS. Une alerte TLS dans le journal signifie que l’enveloppe a été acceptée et que l’échec s’est déplacé vers l’intérieur, ce qui est une autre enquête avec une autre correction.

La gestion de la direction se situe aussi ici. Quand un fichier de clé statique est utilisé avec tls-auth, les deux extrémités prennent des directions de clé opposées, et le protocole utilise cette répartition pour qu’un paquet capturé ne puisse pas être réfléchi vers son émetteur. Inverser la direction garde la clé identique et fait pourtant échouer chaque paquet. Changez une extrémité à la fois, puis redémarrez les deux démons pour que la paire soit chargée ensemble.

Alignez clé, direction et digest aux deux extrémités

Trois valeurs doivent concorder et une seule d’entre elles est le fichier. Le contenu de la clé statique doit être identique aux deux extrémités, la direction doit être opposée et le digest utilisé pour le HMAC doit correspondre. Vérifiez la configuration avant de toucher au matériel de clé, car une seule direction inversée explique plus d’échecs qu’un fichier corrompu :

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Générez le secret partagé avec l’outil plutôt qu’avec un éditeur, et gardez des permissions strictes :

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Les anciennes versions acceptaient un ordre d’options légèrement différent pour la génération de clé, et les profils écrits pour ces versions circulent encore. Le fichier généré est le même type d’objet dans les deux cas, donc la vérification consiste à savoir si les deux extrémités détiennent des octets identiques, et non quelle orthographe les a produits.

Ne confondez pas tls-auth avec tls-crypt. Les deux protègent le canal de contrôle, mais tls-crypt le chiffre aussi et cache la poignée de main aux observateurs, et il remplace la répartition des directions par sa propre gestion de clé. Un profil qui utilise l’un n’interopérera pas avec un pair configuré pour l’autre, et aucun réglage de digest ne comble cet écart.

Ne reproduisez une étiquette qu’à partir du format réel

La reproduction exacte à l’octet est une tâche distincte de l’exploitation d’un VPN, et elle ne fonctionne qu’avec les entrées réelles : l’implémentation et la version qui ont construit le paquet, le digest choisi, la direction, et les octets réels, y compris l’identifiant de session et le tableau d’acquittement. Un rendu textuel de la liste des champs n’est pas ces octets.

La longueur de l’étiquette découle du digest, donc une hypothèse de longueur fixe se brise dès que quelqu’un la change. Hachez le paquet comme le fait l’implémentation, pas comme le présente un tableau dans un billet de blog, et comparez à une capture prise du même pair plutôt qu’à une attente déduite à la main.

Gardez cet exercice loin des profils de production. Rien dans la reproduction d’une étiquette ne vous dit si un déploiement devrait activer la protection.

Annulez un désaccord sans retirer la protection

Le test tentant consiste à supprimer tls-auth, à voir la connexion réussir et à conclure que la clé était fausse. Cette réponse vous coûte la protection et n’apprend rien sur laquelle des trois valeurs divergeait. Récupérez plutôt la configuration correspondante approuvée côté serveur et comparez avec elle.

Préparez le changement pour qu’il soit réversible. Conservez la configuration et le fichier de clé précédents du serveur, appliquez la paire corrigée, vérifiez qu’un client termine la poignée de main, et seulement alors supprimez la sauvegarde. Si des clients échouent après le changement, restaurez les fichiers précédents au lieu d’improviser une troisième variante pendant une panne. La restauration doit être une commande que vous connaissez déjà avant de commencer.

Enfin, rappelez-vous ce que signifie une vérification réussie. Elle prouve que le pair détient la clé partagée, non que son certificat ou son compte soit autorisé, et elle ne dit rien du chiffrement négocié du canal de données. L’autorisation et la protection des données sont établies plus tard, donc une vérification propre de l’enveloppe est un point de départ et non un verdict.