0x eller 0s? Slik leser du PSK-formatet i ipsec.secrets

Én klient autentiserer med den delte nøkkelen, og en annen avviser den, selv om tegnene du limte inn ser like ut på begge sider. De er sannsynligvis de samme tegnene; forskjellen er hvilken avkodingsregel filen bruker på dem. En streng i anførselstegn tas bokstavelig, et token som begynner med 0x leses som heksadesimalt, og et token som begynner med 0s leses som Base64. Bare én av de tre skrivemåtene betyr det du mente, så rettelsen er som regel en konvertering og ikke et bedre passord.

Symptomet peker på koding, ikke på chiffere

Når de to endene har ulike byte, lykkes forhandlingen fortsatt, og beviset feiler etterpå. Loggen rapporterer da en integritets- eller HMAC-feil i stedet for en algoritmeforskjell, fordi et forslag ble valgt og autentiseringstrinnet ikke passet. Den linjen nevner aldri hemmelighetens form.

Trinnet er sporet. En feil som kommer etter et valgt forslag, betyr at begge sider ble enige om alt unntatt nøkkelmateriale, mens «ingen forslag valgt» hører til policy eller chiffersett. En integritetssjekk som feiler mens passordet ser riktig ut, er den synlige siden av en kodeforskjell.

Én hemmelighet, tre måter filen kan lese den på

For verdien på fire byte key1 er heksadesimal og Base64 to omkodinger av de samme bytene, og bare de ledende tegnene forteller parseren hvilken av dem den holder. swanctl-legitimasjon følger samme konvensjon, så en verdi som flyttes mellom de to grensesnittene, beholder bare betydningen når prefikset reiser med.

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

To detaljer i den blokken koster mest tid. Heksadesimale sifre godtar begge skrivemåtene, så 0x6b657931 og 0x6B657931 er samme verdi, men et oddetall tegn leses stille feil i stedet for å bli avvist, noe som forskyver hver byte etter kuttet. Base64-utfylling hører til verdien, så en streng som limes inn uten de avsluttende = tegnene, dekodes til andre byte i stedet for å feile høylytt.

En profil som én gang har dekodet verdien, har allerede konvertert den, så ny dekoding gir andre byte og en autentiseringsfeil som leses som et feil passord. Anførselstegn er den trygge retningen for alt tvetydig, fordi innholdet er bokstavelig selv når det begynner med en kodingsmarkør.

Hvor Base64-teksten kommer fra

Profiluttrekk og leverandørportaler gir ofte nøkkelen allerede kodet, vanligvis i et datafelt som aldri var ment å skrives inn for hånd. Enten pakk ut den verdien og lagre den dekodede teksten i anførselstegn, eller la den være kodet med markøren foran. Å gjøre halvparten av hver er det som ødelegger. Begge veiene virker bare hvis hele verdien overlever kopieringen.

Begge retningene er én kommando hver, og de er verdt å beholde i ticketen som den nøyaktige operasjonen som lagde den lagrede verdien. Kjør dem i denne rekkefølgen:

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

Å lime inn kodet tekst som om den var vanlig, er den dyre feilen. Filen hasher tegnene nøyaktig som skrevet, den utledede nøkkelen blir omtrent en tredjedel lengre enn den motparten beregnet, og hvert forsøk feiler på samme måte uten varsel, fordi parseren fulgte regelen den fikk.

Bekreft hvilke byte hver motpart faktisk bruker

Les først daemonens syn på forbindelsen og deretter autentiseringsresultatet, i stedet for å gjette en årsak fra feilteksten. Å sammenligne den lagrede lengden er en rask fornuftssjekk, fordi kodet tekst er lengre enn bytene den representerer. Bekreft så hvilken identitetsrad som passet, fordi en riktig hemmelighet plassert under feil motpart feiler akkurat som en gal. Rekkefølgen på radene avgjør det: den første treffen vinner, så en bred %any rad nær toppen erstatter stille den spesifikke raden du nettopp redigerte.

Last inn på nytt i stedet for å starte på nytt når filen er riktig. ipsec rereadsecrets oppdaterer kopien til IKE-daemonen, og et swanctl-oppsett laster legitimasjon gjennom sin egen kommando. En omstart slipper hver etablert assosiasjon og ødelegger sammenligningen du prøvde å gjøre.

Ingen av disse sjekkene krever å avsløre hemmeligheten. En lengde, en identitetsvelger og en radposisjon forklarer de fleste slike feil før noen trenger en hex-dump.

Endre filen uten å skjule resultatet

Begrens filen til daemonens konto, og hold levende hemmeligheter ute av tickets, chat og skjermbilder, fordi en innlimt nøkkel er en lekkasje og ikke en diagnose. Den overlever også hendelsen som lagde den.

Test fra en klient du kontrollerer konfigurasjonen til, bekreft at autentiseringen lykkes, og bekreft deretter at tunnelen fører trafikk. En nyinnlasting som reparerer håndtrykket mens rutingen forblir ødelagt, er et annet problem, og det blir synlig så snart hemmeligheten slutter å bevege seg.