Cette clé OpenVPN publiée est-elle une CA, une clé de pair ou tls-auth ?

Quelqu’un signale que la clé VPN est publique, et cette phrase cache trois situations complètement différentes. Il peut s’agir d’un certificat de CA que chaque client est censé posséder, d’une clé d’identité privée qui n’aurait jamais dû quitter une seule machine, ou bien d’un secret partagé du canal de contrôle que les deux extrémités doivent détenir. La réparation, l’urgence et l’ampleur des dégâts diffèrent dans chaque cas, donc la première tâche est la classification et non l’action. Si vous vous trompez de catégorie, chaque étape suivante est un effort perdu.

Partez de la directive, pas du nom de fichier

Lisez la configuration active et trouvez quelle directive pointe vers le matériel en question. Les options TLS d’OpenVPN utilisent ca pour le matériel de certificat de confiance, cert pour le certificat du pair local et key pour la clé privée qui lui correspond.

Les noms de fichiers ne prouvent rien. Un fichier nommé key.pem peut contenir un certificat, et un bloc intégré au profil peut contenir exactement le même objet qu’un fichier séparé sur le disque. Ouvrez le fichier et regardez son en-tête au lieu de faire confiance au nom. Cette seule vérification élimine l’essentiel de l’ambiguïté du rapport.

Si le profil est un paquet PKCS#12, décompressez-le dans un endroit contrôlé pour voir ce qu’il contient réellement. Un seul paquet peut porter un certificat, sa chaîne et une clé privée, ce qui signifie qu’une fuite du paquet est une fuite des trois.

Écrivez la classification avant que quiconque modifie un fichier : objet, directive, quels pairs le détiennent et qui peut le lire. C’est de cette phrase que dépend le reste de la réponse.

Un certificat de CA est conçu pour être partagé

Un certificat de CA public est du matériel de confiance. Les clients en ont besoin pour vérifier le serveur, et le distribuer est le cas normal et non un incident. Le publier ne publie pas la clé de signature privée de la CA, qui est l’objet qui permettrait à un attaquant de fabriquer de nouvelles identités.

Cette distinction mérite d’être écrite explicitement dans le ticket, car les deux sont confondues en permanence. La question à trancher est de savoir si le fichier divulgué est le certificat ou la clé de signature, et un coup d’œil rapide au contenu du fichier suffit à la régler. Un certificat porte une clé publique et une signature ; la clé de signature n’y figure pas du tout.

La distribution mérite tout de même du soin. Les clients devraient obtenir le certificat par le canal approuvé de livraison des profils, et non depuis un site de collage, et un certificat qui arrive par une voie non fiable peut être remplacé en transit.

Une clé de pair et un secret tls-auth ne sont pas

La clé privée d’un pair est du matériel d’identité. Une fois copiée, le serveur ne peut plus distinguer l’appareil prévu de quiconque détient la copie, car la possession exclusive était la propriété démontrée. Poursuivre l’autorisation et procéder au remplacement sont des décisions du propriétaire du VPN, pas de celui qui a trouvé le fichier.

Un secret tls-auth est une troisième chose. Il ajoute une authentification HMAC autour des paquets du canal de contrôle afin que ceux qui sont mal authentifiés soient écartés avant un échange TLS, et il n’est ni la clé privée du pair ni la clé qui chiffre les données applicatives.

Si ce secret partagé est public, la barrière qu’il offrait a disparu pour tous ceux qui le détiennent. Il ne s’ensuit pas que chaque détenteur franchisse les contrôles de certificat et d’utilisateur qui se trouvent derrière, et c’est pourquoi la classification compte plus que le niveau d’alerte. Dites quelle barrière est tombée, et dites lesquelles subsistent.

Réparez le rôle qui a fuité, pas un voisin

Un secret partagé ne redevient pas privé en renommant le fichier ou en cachant le lien de téléchargement. Le remplacement signifie générer une nouvelle valeur et la distribuer à chaque pair lors d’un changement coordonné, et ne remplacer qu’un côté casse l’accord pour tous ceux qui détiennent encore l’ancienne valeur.

Si l’identité d’un pair a été exposée, utilisez la procédure de révocation et de réenrôlement de l’opérateur pour cette identité. Changer le mot de passe d’un compte sans rapport n’invalide pas un certificat copié, et remplacer le fichier tls-auth non plus.

Confirmez ce que le serveur déployé applique réellement avant de vous fier à l’un de ces éléments. Une liste de révocation qui n’est pas rafraîchie, ou un contrôle de rôle désactivé pendant une panne, changent entièrement la réponse. Lisez la configuration en cours et non la copie du dépôt.

Jugez le trafic passé selon ses propres termes

Un fichier exposé ne dit pas à lui seul si des sessions capturées auparavant peuvent être déchiffrées. Cela dépend de la méthode d’établissement des clés, du matériel exposé et des enregistrements qui existent, et « tout le trafic est perdu » comme « rien ne s’est produit » sont des suppositions sans ces faits.

Ne publiez pas une autre copie de l’identifiant pendant que vous demandez à quelle catégorie il appartient. Partagez plutôt les noms de directives et les métadonnées non secrètes par le canal de support approuvé.

La conclusion utile nomme l’objet, son rôle, la protection perdue et l’action coordonnée requise. Tout ce qui est plus court est un titre et non une évaluation.