OpenVPN tls-crypt-v2 : ce que font la clé client et le blob enveloppé
Un profil tls-crypt-v2 contient une clé de contrôle client et une copie enveloppée que seul le serveur peut ouvrir. Gardez chaque objet, et chaque étape de retrait, séparés.
Coller un profil tls-crypt-v2 dans un ticket semble inoffensif tant qu'on n'a pas compté ce que contient le fichier. La clé du canal de contrôle du client se trouve à côté d'une copie chiffrée de cette même clé, et un troisième objet, la clé d'enveloppement, ne quitte jamais le serveur qui accepte. Ces trois objets répondent à des questions différentes sur la garde, le partage et le retrait. Les séparer règle la plupart des débats de politique avant qu'ils ne commencent.
Ce que le profil contient réellement
La moitié client de tls-crypt-v2 est une clé plus une copie enveloppée de celle-ci. Le client utilise la clé simple pour la protection du canal de contrôle et remet la copie enveloppée au serveur lors de la configuration, de sorte que le serveur récupère la même clé sans stocker de copie en clair par client. La clé d'enveloppement rend cette récupération possible et n'appartient qu'au côté qui accepte. Tout ce qui suit découle de l'endroit où vivent ces trois objets.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Lisez le tableau par garde plutôt que par nom, et les conséquences tombent d'elles-mêmes. Perdre la clé d'enveloppement est l'événement coûteux, car rien dans un profil ne peut la reconstruire et la récupération honnête consiste à réémettre le groupe. Un profil fuité coûte moins cher mais est bien plus courant, car les profils sont collés dans des tickets par des gens qui croient que la copie enveloppée rend le fichier sûr à partager. Les deux échecs exigent des réponses différentes, et c'est la raison de garder les objets séparés.
Pourquoi la copie enveloppée n'est pas toute l'histoire
Un profil porte le matériel client utilisable avec sa contrepartie enveloppée, donc protéger la copie destinée au serveur ne dit rien sur la protection du fichier. Le blob est sûr à transmettre et dangereux à publier. Les métadonnées qu'il contient sont visibles par quiconque reçoit le blob, y compris par quiconque lira plus tard le ticket dans lequel il a été collé.
Traitez un profil comme un titre d'accès, non comme un exemple de configuration. Un fichier fuité donne à son détenteur une identité client opérationnelle jusqu'à ce que le serveur cesse d'accepter cette identité, et l'enveloppement ne fait rien contre cette fenêtre. Émettez un profil par client pour que le retrait reste une décision sur un seul fichier, et sauvegardez la clé d'enveloppement séparément de la configuration serveur qu'elle rend possible. Aucune des deux habitudes ne répare un profil compromis, mais toutes deux décident de la rapidité avec laquelle le suivant sera contenu.
Où se situe le hook de vérification dans la poignée de main
Le hook de vérification s'exécute avant que la pile TLS ne soit exposée, et son rôle est d'inspecter les métadonnées portées dans le blob enveloppé. Il reçoit ces métadonnées plus un environnement petit et documenté, et il a moins de moyens qu'un hook d'authentification. Supposer qu'il voit les noms d'utilisateur, l'état de session ou les variables d'extension est la façon habituelle de mal écrire ce hook. Lisez la section du manuel propre au hook au lieu d'emprunter des attentes à un autre hook.
Son statut de sortie est la décision : un résultat non nul refuse le client et un résultat nul laisse la poignée de main continuer. La politique doit donc dire ce qui se passe quand les métadonnées manquent, sont illisibles ou inattendues. Écrivez d'abord le chemin de refus, puis décidez quelles valeurs sont acceptables.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shCes deux lignes sont la surface de politique sur le serveur : l'une nomme la clé d'enveloppement, l'autre nomme le programme qui juge chaque client. Tout l'intéressant vit dans le script, qui mérite le contrôle de version et la même revue que toute autre règle d'accès.
Compte, certificat et clé de contrôle se retirent séparément
L'acceptation précoce du canal de contrôle n'est pas une authentification, car elle a lieu avant la vérification d'identité TLS et avant toute autorisation de compte. Désactiver un compte, révoquer un certificat et refuser une clé de contrôle client sont trois actions avec trois mécanismes. Un déploiement qui n'en exécute qu'une a une lacune et non une politique. Réconciliez les trois délibérément et notez quelle étape exerce quelle autorité.
Le moment est la seconde distinction. Une liste d'acceptation modifiée s'applique aux nouvelles poignées de main, tandis que les sessions déjà établies continuent jusqu'à ce que quelque chose les termine. Compter les entrées de la nouvelle liste comme preuve que les anciennes sessions ont pris fin, c'est ainsi qu'un client supprimé reste connecté pendant des heures.
Des autorités non réconciliées laissent deux trous faciles à trouver en pratique. Un compte peut être désactivé alors que sa clé de contrôle ouvre encore une poignée de main, et un certificat peut être révoqué alors que la politique de métadonnées admet encore le même client. Les deux sont la même erreur à des endroits différents, parce qu'un opérateur a traité une liste comme toute l'autorité. Placez les trois listes côte à côte au moment du retrait et l'erreur devient visible.
Émettre et retirer un profil
L'émission est la moitié facile : créez la clé client du côté qui accepte, remettez le profil à exactement un propriétaire, gardez le matériel d'enveloppement restreint et exécutez le même programme de vérification sur chaque serveur qui accepte. L'admission bon marché est une propriété du groupe entier, pas de l'hôte le plus récent. Un second serveur avec un script plus ancien ou plus laxiste devient silencieusement le chemin le plus faible du déploiement.
Le retrait exige les trois étapes dans un ordre réfléchi. Refusez le client dans le hook de vérification pour que les nouvelles poignées de main échouent, révoquez son certificat si une PKI est utilisée, et désactivez le compte pour que l'autorisation ultérieure n'ait plus rien à autoriser. Terminez ensuite les sessions que l'ancienne acceptation permettait, car elles ne remarqueront aucune des trois. Répétez la séquence sur un client que vous pouvez vous permettre de casser.
Les métadonnées d'un profil sont une entrée pour cette politique, non la preuve qu'un contrôle d'accès existe déjà. Le document de conception d'OpenVPN 2.6 décrit les objets et la frontière qu'ils dessinent, tandis que l'application reste du ressort de l'opérateur.