Votre profil VPN contient une clé privée, pas seulement des réglages
Les adresses de serveurs côtoient des clés privées, des secrets intégrés et des jetons. Avant de coller un profil dans un fil d’assistance, sachez quelles lignes constituent l’identité.
Toute personne qui colle un profil VPN dans un fil de forum part de la même croyance. Le fichier ne contient qu’une adresse de serveur et quelques options, alors le partager revient à partager un numéro de téléphone. Puis quelqu’un le lit et trouve une clé privée non chiffrée à la quatrième ligne.
Le profil n’est pas de la documentation sur le tunnel. C’est l’identité du tunnel, écrite.
Les objets du fichier n’ont pas le même niveau de secret
Un certificat CA public est fait pour voyager. Une clé privée de client, non. Quand les deux figurent dans le même fichier, l’inoffensif fait paraître toute la pièce jointe sûre. C’est le piège.
OpenVPN aggrave cela par conception. Il permet d’intégrer certificats, clés et éléments d’authentification directement. C’est pratique pour le déploiement et désastreux pour le partage. Le fichier qui commence par un bloc de certificat lisible se poursuit dans la moitié privée.
WireGuard est plus direct. La section d’interface porte une clé privée, et chaque peer peut en plus porter une clé pré-partagée. Aucune ambiguïté sur les lignes qui comptent. Presque toutes comptent.
Une capture d’écran est la même fuite sous un autre format
Encoder une configuration en QR code ne la classe pas comme aperçu. Le code porte les mêmes octets, et n’importe quel appareil photo de la pièce peut le décoder. Il en va de même pour une capture de la fenêtre de configuration d’un client, où la clé est lisible dans le coin.
Les fichiers d’authentification et les chemins de clés référencés relèvent du même audit. Un profil qui pointe vers un fichier externe n’est pas automatiquement plus sûr, car le chemin peut mener quelque part où un lecteur a accès. Un jeton dans un fichier d’authentification est aussi utilisable qu’un mot de passe, et il y ressemble rarement.
Envoyez le texte d’erreur, pas la clé
Le diagnostic a besoin du texte d’erreur, de la version du client et des noms des options essayées. Il n’a pas besoin de la clé. Rédigez la question avec ces trois éléments, et remplacez chaque secret et chaque identifiant réseau inutile avant que le fichier ne quitte votre machine.
La section du manuel OpenVPN sur les fichiers intégrés est une carte utile de l’emplacement de ces objets. Elle rappelle aussi combien un seul profil peut en contenir.
# which lines in this profile look like secrets?
grep -n -E 'PrivateKey|PresharedKey|password|auth-user-pass|BEGIN .*PRIVATE KEY' wg0.conf
# OpenVPN: show the structure without printing key material
awk '/BEGIN/{print NR": "$0} /^[a-z-]+ /{print NR": "$1}' office.ovpn
Lisez ensuite la pièce jointe finale plutôt que de vous fier à votre souvenir de la modification. Les clés se cachent dans des blocs ultérieurs, dans un commentaire non masqué et dans une ligne que vous avez jugée structurelle.
Après une exposition, la rotation est la seule réparation
Supprimer la publication ne révoque rien. Celui qui a reçu le fichier dispose encore d’un identifiant valide, c’est pourquoi l’émetteur doit le révoquer ou le remplacer via le processus propre du service. Retirer une copie locale ne change rien à l’autre bout.
Conservez les profils actifs par une méthode protégée, et supprimez volontairement les entrées importées obsolètes au lieu de laisser trois copies dans un dossier de téléchargements. Un profil que vous n’utilisez plus reste un identifiant jusqu’à sa révocation.
L’habitude qui vaut la peine d’être construite est petite. Avant qu’un profil ne quitte la machine, demandez ce qu’il contient d’autre que l’adresse, et répondez en lisant le fichier plutôt qu’en vous en souvenant.