0x o 0s? Com es llegeix el format PSK a ipsec.secrets

Un client s’autentica amb la clau compartida i un altre la rebutja, i els caràcters que heu enganxat semblen iguals als dos costats. Probablement són els mateixos caràcters; la diferència és quina regla de descodificació hi aplica el fitxer. Una cadena entre cometes es pren literalment, un testimoni que comença per 0x es llegeix com a hexadecimal, i un testimoni que comença per 0s es llegeix com a Base64. Només una d’aquestes tres grafies vol dir el que preteníeu, així que la solució sol ser una conversió i no una contrasenya millor.

El símptoma apunta a la codificació, no als xifrats

Quan els dos extrems tenen bytes diferents, la negociació continua tenint èxit i la prova falla després. Llavors el registre informa d’una fallada d’integritat o d’HMAC en lloc d’una discrepància d’algorisme, perquè s’ha triat una proposta i el pas d’autenticació no ha coincidit. Aquella línia no esmenta mai la forma del secret.

L’etapa és la pista. Una fallada que arriba després d’una proposta triada vol dir que tots dos costats s’han posat d’acord en tot excepte en el material de clau, mentre que «cap proposta triada» pertany a la política o als conjunts de xifratge. Una comprovació d’integritat que falla quan la contrasenya sembla correcta és la cara visible d’una discrepància de codificació.

Un secret, tres maneres com el fitxer el pot llegir

Per al valor de quatre bytes key1, l’hexadecimal i el Base64 són dues recodificacions dels mateixos bytes, i només els caràcters inicials diuen a l’analitzador quin dels dos té a les mans. Les credencials de swanctl segueixen la mateixa convenció, així que un valor traslladat entre les dues interfícies conserva el significat només si el seu prefix viatja amb ell.

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

Dos detalls d’aquell bloc costen la major part del temps. Els dígits hexadecimals accepten qualsevol de les dues caixes, així que 0x6b657931 i 0x6B657931 són el mateix valor, però un nombre senar de caràcters es llegeix malament en silenci en lloc de ser rebutjat, cosa que desplaça cada byte després del tall. L’emplenament del Base64 forma part del valor, així que una cadena enganxada sense els seus signes = finals es descodifica en bytes diferents en lloc de fallar sorollosament.

Un perfil que ha descodificat el valor una vegada ja l’ha convertit, així que tornar-lo a descodificar produeix bytes diferents i una fallada d’autenticació que es llegeix com una contrasenya equivocada. Les cometes són la direcció segura per a qualsevol cosa ambigua, perquè el contingut és literal fins i tot quan comença amb un marcador de codificació.

D’on surt el text Base64

Les exportacions de perfils i els portals de proveïdors sovint lliuren la clau ja codificada, normalment en un camp de dades que mai no s’havia de teclejar a mà. O bé desfeu aquell valor i guardeu el text descodificat entre cometes, o bé deixeu-lo codificat amb el marcador al davant. Fer la meitat de cada cosa és el que ho trenca. Tots dos camins funcionen només si el valor sencer sobreviu a la còpia.

Totes dues direccions són una ordre cadascuna, i val la pena guardar-les al tiquet com l’operació exacta que va produir el valor desat. Executeu-les en aquest ordre:

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

Enganxar text codificat com si fos pla és l’error car. El fitxer calcula el hash dels caràcters exactament tal com s’han escrit, la clau derivada surt aproximadament un terç més llarga que la que ha calculat el company, i cada intent falla de la mateixa manera sense cap avís, perquè l’analitzador ha seguit la regla que li han donat.

Confirmeu quins bytes fa servir realment cada company

Llegiu primer com veu el dimoni la connexió i després el resultat de l’autenticació, en lloc d’endevinar una causa a partir de la cadena d’error. Comparar la longitud desada és una comprovació ràpida de sensatesa, perquè el text codificat és més llarg que els bytes que representa. Després confirmeu quina fila d’identitat ha coincidit, perquè un secret correcte arxivat sota el company equivocat falla igual que un d’equivocat. L’ordre de les files ho decideix: la primera coincidència guanya, així que una fila àmplia %any a prop de dalt substitueix en silenci la fila concreta que acabeu d’editar.

Recarregueu en lloc de reiniciar quan el fitxer sigui correcte. ipsec rereadsecrets refresca la còpia del dimoni IKE, i una instal·lació amb swanctl carrega les credencials amb la seva pròpia ordre. Un reinici elimina totes les associacions establertes i destrueix la comparació que intentàveu fer.

Cap d’aquestes comprovacions no exigeix exposar el secret. Una longitud, un selector d’identitat i una posició de fila expliquen la majoria de fallades d’aquest tipus abans que ningú necessiti un bolcat hexadecimal.

Canvieu el fitxer sense amagar el resultat

Restringiu el fitxer al compte del dimoni i mantingueu els secrets actius fora dels tiquets, del xat i de les captures de pantalla, perquè una clau enganxada és una filtració i no un diagnòstic. També sobreviu a l’incident que l’ha produït.

Proveu des d’un client la configuració del qual controleu, confirmeu que l’autenticació té èxit i després confirmeu que el túnel transporta trànsit. Una recàrrega que arregla l’encaixada de mans mentre l’encaminament continua trencat és un altre problema, i es fa visible tan bon punt el secret deixa de moure’s.