0x sau 0s? Cum se citește formatul PSK din ipsec.secrets

Un client se autentifică cu cheia partajată, iar altul o respinge, deși caracterele lipite arată la fel pe ambele părți. Probabil sunt aceleași caractere; diferența stă în ce regulă de decodare aplică fișierul asupra lor. Un șir între ghilimele este luat literal, un token care începe cu 0x este citit ca hexazecimal, iar un token care începe cu 0s este citit ca Base64. Doar una dintre aceste trei scrieri înseamnă ceea ce ați intenționat, așa că remedierea este de obicei o conversie, nu o parolă mai bună.

Simptomul indică codificarea, nu cifrurile

Când cele două capete țin octeți diferiți, negocierea reușește în continuare, iar dovada eșuează după aceea. Jurnalul raportează atunci o defecțiune de integritate sau HMAC în locul unei nepotriviri de algoritm, pentru că a fost aleasă o propunere, iar pasul de autentificare nu s-a potrivit. Acea linie nu menționează niciodată forma secretului.

Etapa este indiciul. O defecțiune care apare după o propunere aleasă înseamnă că ambele părți au căzut de acord asupra tuturor aspectelor în afară de materialul cheii, în timp ce „nicio propunere aleasă” ține de politică sau de seturile de cifruri. O verificare de integritate care eșuează în timp ce parola pare corectă este fața vizibilă a unei nepotriviri de codificare.

Un secret, trei moduri în care fișierul îl poate citi

Pentru valoarea de patru octeți key1, hexazecimalul și Base64 sunt două recodificări ale acelorași octeți, iar doar caracterele inițiale îi spun analizatorului pe care dintre ele îl ține. Acreditările swanctl urmează aceeași convenție, așa că o valoare mutată între cele două interfețe își păstrează sensul doar dacă prefixul ei călătorește împreună cu ea.

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

Două detalii din acel bloc consumă cel mai mult timp. Cifrele hexazecimale acceptă ambele scrieri, deci 0x6b657931 și 0x6B657931 sunt aceeași valoare, dar un număr impar de caractere este citit greșit în tăcere în loc să fie respins, ceea ce deplasează fiecare octet după tăietură. Umplerea Base64 face parte din valoare, așa că un șir lipit fără semnele = finale este decodat în alți octeți în loc să eșueze zgomotos.

Un profil care a decodat valoarea o dată a convertit-o deja, așa că decodarea din nou produce alți octeți și o defecțiune de autentificare care se citește ca o parolă greșită. Ghilimelele sunt direcția sigură pentru orice este ambiguu, pentru că conținutul este literal chiar și atunci când începe cu un marcator de codificare.

De unde vine textul Base64

Exporturile de profil și portalurile furnizorilor predau adesea cheia deja codificată, de obicei într-un câmp de date care nu a fost niciodată gândit pentru tastare manuală. Fie despachetați acea valoare și păstrați textul decodat între ghilimele, fie lăsați-o codificată cu marcatorul în față. A face jumătate din fiecare este ceea ce strică. Ambele căi funcționează doar dacă întreaga valoare supraviețuiește copierii.

Ambele direcții sunt o comandă fiecare, și merită păstrate în tichet ca operația exactă care a produs valoarea stocată. Rulați-le în această ordine:

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

Lipirea textului codificat ca și cum ar fi simplu este greșeala costisitoare. Fișierul aplică hash caracterelor exact așa cum sunt scrise, cheia derivată iese cu aproximativ o treime mai lungă decât cea calculată de partener, iar fiecare încercare eșuează la fel, fără avertisment, pentru că analizatorul a urmat regula care i-a fost dată.

Confirmați ce octeți folosește de fapt fiecare partener

Citiți mai întâi viziunea demonului asupra conexiunii și apoi rezultatul autentificării, în loc să ghiciți o cauză din șirul erorii. Compararea lungimii stocate este o verificare rapidă de bun simț, pentru că textul codificat este mai lung decât octeții pe care îi reprezintă. Apoi confirmați ce rând de identitate s-a potrivit, pentru că un secret corect plasat sub partenerul greșit eșuează exact ca unul greșit. Ordinea rândurilor decide acest lucru: prima potrivire câștigă, așa că un rând larg %any aproape de vârf înlocuiește în tăcere rândul specific pe care tocmai l-ați editat.

Reîncărcați în loc să reporniți după ce fișierul este corect. ipsec rereadsecrets reîmprospătează copia demonului IKE, iar o instalare swanctl încarcă acreditările prin propria comandă. O repornire aruncă fiecare asociere stabilită și distruge comparația pe care încercați să o faceți.

Niciuna dintre aceste verificări nu cere expunerea secretului. O lungime, un selector de identitate și o poziție de rând explică majoritatea defecțiunilor de acest tip înainte ca cineva să aibă nevoie de un dump hexazecimal.

Modificați fișierul fără a ascunde rezultatul

Restrângeți fișierul la contul demonului și țineți secretele vii în afara tichetelor, a chatului și a capturilor de ecran, pentru că o cheie lipită este o scurgere, nu un diagnostic. De asemenea, supraviețuiește incidentului care a produs-o.

Testați de la un client a cărui configurație o controlați, confirmați că autentificarea reușește, apoi confirmați că tunelul transportă trafic. O reîncărcare care repară strângerea de mână în timp ce rutarea rămâne stricată este o altă problemă și devine vizibilă de îndată ce secretul încetează să se miște.