0x ou 0s ? Décoder le format PSK dans ipsec.secrets

Un client s’authentifie avec la clé partagée et un autre la rejette, alors que les caractères collés semblent identiques des deux côtés. Ce sont probablement les mêmes caractères ; la différence tient à la règle de décodage que le fichier leur applique. Une chaîne entre guillemets est prise littéralement, un jeton commençant par 0x est lu comme hexadécimal, et un jeton commençant par 0s est lu comme Base64. Une seule de ces trois écritures signifie ce que vous vouliez, aussi la correction est-elle généralement une conversion et non un meilleur mot de passe.

Le symptôme pointe l’encodage, pas les chiffrements

Quand les deux extrémités détiennent des octets différents, la négociation aboutit quand même et la preuve échoue ensuite. Le journal signale alors une défaillance d’intégrité ou HMAC plutôt qu’une incompatibilité d’algorithme, car une proposition a été choisie et l’étape d’authentification n’a pas correspondu. Cette ligne ne mentionne jamais la forme du secret.

L’étape est l’indice. Une défaillance qui arrive après une proposition choisie signifie que les deux côtés se sont accordés sur tout sauf le matériel de clé, tandis que « aucune proposition choisie » relève de la politique ou des suites de chiffrement. Un contrôle d’intégrité qui échoue alors que le mot de passe semble correct est la face visible d’une incompatibilité d’encodage.

Un secret, trois façons dont le fichier peut le lire

Pour la valeur de quatre octets key1, l’hexadécimal et le Base64 sont deux réencodages des mêmes octets, et seuls les caractères de tête indiquent à l’analyseur lequel il tient. Les identifiants swanctl suivent la même convention, aussi une valeur déplacée entre les deux interfaces ne garde son sens que si son préfixe voyage avec elle.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Deux détails de ce bloc coûtent le plus de temps. Les chiffres hexadécimaux acceptent les deux casses, donc 0x6b657931 et 0x6B657931 sont la même valeur, mais un nombre impair de caractères est lu de travers en silence au lieu d’être rejeté, ce qui décale chaque octet après la coupure. Le remplissage Base64 fait partie de la valeur, donc une chaîne collée sans ses signes = finaux se décode en octets différents au lieu d’échouer bruyamment.

Un profil qui a décodé la valeur une fois l’a déjà convertie, donc décoder à nouveau produit des octets différents et un échec d’authentification qui se lit comme un mauvais mot de passe. Les guillemets sont la direction sûre pour tout ce qui est ambigu, car le contenu est littéral même lorsqu’il commence par un marqueur d’encodage.

D’où vient le texte Base64

Les exports de profil et les portails de fournisseurs livrent souvent la clé déjà encodée, généralement dans un champ de données qui n’a jamais été prévu pour la saisie manuelle. Soit vous déballez cette valeur et stockez le texte décodé entre guillemets, soit vous la laissez encodée avec le marqueur devant. Faire la moitié de chacun est ce qui casse. Les deux chemins ne fonctionnent que si la valeur entière survit à la copie.

Les deux directions sont une commande chacune, et elles méritent de rester dans le ticket comme l’opération exacte qui a produit la valeur stockée. Exécutez-les dans cet ordre :

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Coller du texte encodé comme s’il était en clair est l’erreur coûteuse. Le fichier hache les caractères exactement tels qu’ils sont écrits, la clé dérivée ressort environ un tiers plus longue que celle calculée par le pair, et chaque tentative échoue de la même manière sans avertissement, parce que l’analyseur a suivi la règle qui lui a été donnée.

Confirmez quels octets chaque pair utilise réellement

Lisez d’abord la vue du démon sur la connexion puis le résultat de l’authentification, plutôt que de deviner une cause à partir de la chaîne d’erreur. Comparer la longueur stockée est un contrôle de bon sens rapide, car le texte encodé est plus long que les octets qu’il représente. Confirmez ensuite quelle ligne d’identité a correspondu, car un secret correct rangé sous le mauvais pair échoue exactement comme un secret erroné. L’ordre des lignes décide de cela : la première correspondance l’emporte, donc une ligne large %any près du haut remplace silencieusement la ligne précise que vous venez de modifier.

Rechargez au lieu de redémarrer une fois le fichier correct. ipsec rereadsecrets rafraîchit la copie du démon IKE, et une installation swanctl charge les identifiants par sa propre commande. Un redémarrage abandonne chaque association établie et détruit la comparaison que vous tentiez de faire.

Aucun de ces contrôles n’exige d’exposer le secret. Une longueur, un sélecteur d’identité et une position de ligne expliquent la plupart des échecs de ce genre avant que quiconque ait besoin d’un vidage hexadécimal.

Modifiez le fichier sans masquer le résultat

Restreignez le fichier au compte du démon et gardez les secrets actifs hors des tickets, du chat et des captures d’écran, car une clé collée est une fuite et non un diagnostic. Elle survit aussi à l’incident qui l’a produite.

Testez depuis un client dont vous contrôlez la configuration, confirmez que l’authentification réussit, puis confirmez que le tunnel transporte du trafic. Un rechargement qui répare la poignée de main alors que le routage reste cassé est un autre problème, et il devient visible dès que le secret cesse de bouger.