Clé pré-partagée IPsec : les octets derrière la chaîne que vous avez saisie

Deux administrateurs comparent le secret à l’écran, conviennent qu’il correspond, et le tunnel échoue quand même à l’authentification. La chaîne qu’ils ont comparée n’est pas la valeur que l’une ou l’autre extrémité injecte dans la dérivation de clé. Entre les caractères que vous voyez et les octets que le protocole hache, il y a un type de champ, un encodage de texte, un éditeur et un presse-papiers, et l’un des quatre peut modifier l’entrée sans changer son apparence. Comparez les octets et le désaccord apparaît généralement en quelques secondes.

Ce que la passerelle fait de la chaîne

Une clé pré-partagée n’est pas envoyée sur le réseau puis comparée. Chaque extrémité injecte sa copie locale dans la dérivation de clé pour l’échange IKE, et les charges utiles d’authentification qui en résultent se vérifient ou non. Cette conception signifie que les deux copies doivent être identiques octet par octet plutôt que visuellement similaires, et elle signifie aussi que l’échec est signalé à l’étape d’authentification plutôt que comme un message de mot de passe incorrect.

Ainsi, la question utile n’est jamais « ces chaînes se ressemblent-elles » mais « quelle séquence exacte d’octets chaque implémentation hache-t-elle ».

D’où viennent les octets supplémentaires

Un saut de ligne final est le coupable classique, et il se cache au grand jour parce que la plupart des éditeurs en ajoutent un invisiblement lors de l’enregistrement d’un fichier. Un espace de début ou de fin collé depuis une fenêtre de discussion fait la même chose, tout comme une apostrophe typographique remplacée par une droite par un traitement de texte. Rien de tout cela ne change la comparaison visuelle qu’effectue un humain.

Comparez avec un outil qui montre les octets plutôt que les glyphes. printf '%s' "$PSK" | xxd | tail -2 imprime la fin de la valeur en hexadécimal, où un 0a ou un 20 égaré est évident. Faites-le aux deux extrémités et comparez les deux vidages côte à côte. Faites-le sur du matériel de test généré, pas sur un secret de production que vous laissez ensuite dans l’historique du shell.

Encodé n’est pas chiffré

Les exportations de configuration transportent souvent le secret dans un encodage de base, parfois avec des sauts de ligne tous les soixante ou soixante-seize caractères et parfois avec du remplissage. Si une extrémité attend les octets décodés et que vous collez le texte encodé, vous n’avez pas envoyé un mot de passe différent, vous en avez envoyé un bien plus long composé de caractères imprimables. Base64 n’offre aucune confidentialité, ce qui explique aussi pourquoi un secret encodé ne doit jamais être collé sur un forum pour demander un second avis.

Le dictionnaire IPSec d’Apple est un bon exemple de l’importance du type : il documente SharedSecret comme donnée pour la méthode d’authentification par secret partagé dans les charges utiles L2TP et Cisco IPsec. C’est une propriété précise dans une charge utile précise, pas un champ de texte général que vous pouvez réutiliser pour un autre protocole qui demande par hasard un secret.

Une limite alléguée appartient à une combinaison

Les anciens rapports d’un plafond de trente-deux caractères sur un client Apple sont des rapports réels sur une version de client, un protocole et une forme de profil. Ce ne sont pas une limite universelle pour chaque plateforme Apple, chaque fournisseur et chaque protocole. Vérifiez la version, le type de charge utile et l’exigence de la passerelle ensemble, puis testez sur une configuration approuvée au lieu de déduire d’un fil de discussion. Écrivez la combinaison testée dans le registre des changements, sinon la personne suivante citera le même fil avec plus d’assurance qu’il n’en mérite.

Si une limite s’applique vraiment, la réponse est une conception d’identifiants prise en charge qui s’y conforme, pas une version raccourcie d’un secret fort. Tronquer une clé de production pour satisfaire une limite supposée réduit sa force de façon permanente et produit un système dont la documentation ne correspond plus à sa sécurité.

Corrigez la représentation, pas la force

Lorsque l’authentification échoue après confirmation de la représentation, lisez la politique effective à l’étape d’authentification : quelle méthode est négociée, quelle identité de pair est attendue et si la passerelle correspond à la connexion que vous croyez. Des suppositions de plus en plus faibles ne sont pas un diagnostic, c’est une dégradation lente avec un ticket d’assistance joint.

Si l’identifiant requis ne peut pas respecter la norme de l’organisation, changez la conception pour une qui le peut. Un secret partagé avec suffisamment d’entropie, généré une fois, stocké dans un champ géré et jamais publié, est une réponse parfaitement bonne ; une version plus courte ne l’est pas.