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

Éin klient autentiserer med den delte nøkkelen, og ein annan avviser han, sjølv om teikna du limte inn ser like ut på begge sider. Dei er truleg dei same teikna; skilnaden er kva avkodingsregel fila brukar på dei. Ein streng i hermeteikn blir teken bokstaveleg, eit token som byrjar med 0x blir lese som heksadesimalt, og eit token som byrjar med 0s blir lese som Base64. Berre éin av dei tre skrivemåtane tyder det du meinte, så rettinga er som regel ei omforming og ikkje eit betre passord.

Symptomet peikar på koding, ikkje på chiffer

Når dei to endane har ulike byte, lukkast forhandlinga likevel, og beviset feilar etterpå. Loggen rapporterer då ein integritets- eller HMAC-feil i staden for ein algoritmeskilnad, fordi eit framlegg vart valt og autentiseringstrinnet ikkje passa. Den linja nemner aldri forma på løyndomen.

Trinnet er sporet. Ein feil som kjem etter eit valt framlegg, tyder at begge sider vart samde om alt utanom nøkkelmateriale, medan «ingen framlegg valde» høyrer til policy eller chiffersett. Ein integritetssjekk som feilar medan passordet ser rett ut, er den synlege sida av ein kodeskilnad.

Éin løyndom, tre måtar fila kan lese han på

For verdien på fire byte key1 er heksadesimal og Base64 to omkodingar av dei same byta, og berre dei leidande teikna fortel parsaren kva for ein han held. swanctl-legitimasjon følgjer same konvensjon, så ein verdi som blir flytta mellom dei to grensesnitta, held på tydinga berre 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 detaljar i den blokka kostar mest tid. Heksadesimale siffer godtek begge skrivemåtane, så 0x6b657931 og 0x6B657931 er same verdi, men eit oddetal teikn blir lese stille feil i staden for å bli avvist, noko som forskyv kvar byte etter kuttet. Base64-utfylling høyrer til verdien, så ein streng som blir limt inn utan dei avsluttande = teikna, blir dekoda til andre byte i staden for å feile høgt.

Ein profil som éin gong har dekoda verdien, har alt omforma han, så ny dekoding gir andre byte og ein autentiseringsfeil som blir lese som eit feil passord. Hermeteikn er den trygge retninga for alt tvitydig, fordi innhaldet er bokstaveleg sjølv når det byrjar med ein kodingsmarkør.

Kvar Base64-teksten kjem frå

Profiluttrekk og leverandørportalar gir ofte nøkkelen alt koda, vanlegvis i eit datafelt som aldri var meint å skrivast inn for hand. Anten pakkar du ut den verdien og lagrar den dekoda teksten i hermeteikn, eller lèt han vere koda med markøren framfor. Å gjere halvparten av kvar er det som øydelegg. Begge vegane verkar berre om heile verdien overlever kopieringa.

Begge retningane er éin kommando kvar, og dei er verd å halde i ticketen som den nøyaktige operasjonen som laga den lagra verdien. Køyr dei i denne rekkjefølgja:

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

Å lime inn koda tekst som om han var vanleg, er den dyre feilen. Fila hashar teikna nøyaktig som skrive, den utleia nøkkelen blir om lag ein tredel lengre enn den motparten rekna ut, og kvart forsøk feilar på same måte utan varsel, fordi parsaren følgde regelen han fekk.

Stadfest kva byte kvar motpart faktisk brukar

Les først synet til daemonen på sambandet og deretter autentiseringsresultatet, i staden for å gjette ei årsak frå feilteksten. Å samanlikne den lagra lengda er ein rask fornuftssjekk, fordi koda tekst er lengre enn byta han representerer. Stadfest så kva identitetsrad som passa, fordi ein rett løyndom plassert under feil motpart feilar akkurat som ein galen. Rekkjefølgja på radene avgjer det: den første treffen vinn, så ei brei %any rad nær toppen erstattar stille den spesifikke rada du nettopp redigerte.

Last inn på nytt i staden for å starte på nytt når fila er rett. ipsec rereadsecrets oppdaterer kopien til IKE-daemonen, og eit swanctl-oppsett lastar legitimasjon gjennom sin eigen kommando. Ein omstart slepp kvar etablert assosiasjon og øydelegg samanlikninga du prøvde å gjere.

Ingen av desse sjekkane krev å avsløre løyndomen. Ei lengd, ein identitetsveljar og ein radposisjon forklarer dei fleste slike feil før nokon treng ein hex-dump.

Endre fila utan å skjule resultatet

Avgrens fila til kontoen til daemonen, og hald levande løyndomar ute av tickets, chat og skjermbilde, fordi ein innlimt nøkkel er ei lekkasje og ikkje ein diagnose. Han overlever også hendinga som laga han.

Test frå ein klient du kontrollerer konfigurasjonen til, stadfest at autentiseringa lukkast, og stadfest deretter at tunnelen fører trafikk. Ei nyinnlasting som reparerer handtrykket medan rutinga blir verande øydelagd, er eit anna problem, og det blir synleg så snart løyndomen sluttar å røre seg.