Pourquoi openssl rand ne peut pas créer la clé que tls-crypt attend

OpenSSL est déjà installé, l’hôte dispose d’entropie, et générer une clé avec lui ressemble au raccourci évident. La sortie sera aléatoire, secrète et complètement inutilisable, et l’échec arrive sous forme d’erreur de canal de contrôle plutôt que de quoi que ce soit qui mentionne un format de clé. Cette fausse piste est la partie coûteuse, car elle pousse les gens à inspecter leurs chiffrements. Ce que le VPN lit, c’est une structure de fichier précise, pas un bloc d’octets arbitraire, et une variante de la fonction ne peut pas du tout être produite hors du serveur.

Ce que le fichier sur le disque doit réellement être

Un fichier de clé statique OpenVPN est du texte. Il commence par une ligne de commentaire qui déclare ce qu’il est, transporte des données hexadécimales sur des lignes de largeur fixe et totalise 256 octets de matière de clé. OpenVPN le lit comme le secret partagé du canal de contrôle, pas comme un certificat, pas comme une phrase de passe et pas comme quelque chose qu’une bibliothèque TLS reconnaîtrait.

Le même type d’objet sert aux deux fonctions du canal de contrôle. Avec tls-auth, chaque pair a aussi besoin d’une direction pour que les paquets d’un côté ne puissent pas lui être réfléchis. Avec tls-crypt, un seul secret partagé chiffre et authentifie le canal de contrôle dans les deux sens, ce qui cache la poignée de main tout en la protégeant.

Rien de tout cela n’est un savoir secret, et le format n’est pas le sujet. Le sujet, c’est que le fichier doit correspondre exactement à ce que le lecteur attend : en-tête, largeur de ligne, saut de ligne final et longueur totale. Un fichier décalé d’une ligne se charge comme des déchets ou échoue purement et simplement. Comparer deux pairs octet par octet est donc un premier test légitime, et c’est plus rapide que de lire l’un ou l’autre des fichiers de configuration.

La manière prise en charge d’en fabriquer un

Générez la clé statique simple avec l’outil qui va la consommer, puis référencez-la aux deux extrémités :

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

L’orthographe de l’option a changé avec le temps : les installations plus anciennes de l’ère 2.4 utilisaient une forme avec un indicateur séparé avant le nom de fichier, tandis que les versions actuelles acceptent la plus courte. Dans un cas comme dans l’autre, le fichier obtenu est le même type d’objet, donc la vérification consiste à savoir si les deux pairs détiennent des octets identiques.

La seconde génération ajoute une structure qu’aucun générateur externe ne peut inventer. Une clé serveur est créée une fois, et chaque client reçoit une clé enveloppée dérivée de celle-ci :

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Ce que le client reçoit n’est pas la propre clé du serveur dupliquée. C’est un objet enveloppé portant des métadonnées que seul le serveur peut déballer, et c’est cet enveloppement qui permet à un fichier propre à un appareil d’être révoqué sans toucher aucun autre appareil. Gardez la clé serveur sur le serveur et traitez-la comme la racine de cette confiance par appareil.

Où les octets faits à la main échouent

Imprimer 256 octets aléatoires en hexadécimal sous un en-tête correct donnerait, en théorie, un fichier de clé statique qui se charge. Cela reste une mauvaise idée. Chaque détail de formatage devient une occasion de produire une matière qui échoue au chargement ou, pire, laisse deux pairs avec des valeurs différentes qui ne se révèlent que comme un échec d’authentification.

Rien d’équivalent n’est possible avec la variante v2. Une clé client enveloppée n’existe que comme sortie du processus de clé du serveur, et le serveur conserve la matière nécessaire pour la déballer. Un bloc aléatoire sera rejeté, ou échouera simplement à déchiffrer, et aucun des deux messages ne mentionnera le hasard.

La compatibilité des versions se superpose à tout cela. La première génération exige une version qui la prend en charge aux deux extrémités, et la seconde exige encore une version plus récente. Un client compilé avant l’existence de la fonction ne peut pas terminer une poignée de main avec un serveur qui n’accepte que de la matière enveloppée, et l’échec qu’il signale pointe le canal de contrôle plutôt que la version.

Effectuer une rotation sans enfermer tout le monde dehors

Faire tourner un seul secret partagé est un exercice de coordination plutôt que technique. Chaque client a besoin du fichier de remplacement en main avant que le serveur retire le précédent, et toute machine détenant encore l’ancienne valeur échoue au moment où cela se produit. Ne commencez pas cette rotation au milieu d’une journée de travail.

Avec l’agencement v2, la rotation se fait par appareil : émettez une nouvelle clé enveloppée pour une machine et retirez l’ancienne pour cette seule machine. C’est l’argument principal pour migrer une fois que chaque client est sur une version qui la prend en charge.

Les permissions de fichier relèvent de la même conversation. La clé ne devrait être lisible que par le compte qui exécute le service, et elle ne devrait pas vivre dans le même dépôt que les profils qu’elle protège. La référence OpenVPN 2.6 documente les formes de génération et les sections sur la matière de clé, ce qui est une meilleure source qu’une commande copiée depuis un message de forum.