0x of 0s? It PSK-formaat yn ipsec.secrets lêze

Itselde dielde geheim kin skreaun wurde as in oanhelle literal, as heksadesimaal nei 0x of as Base64 nei 0s. In ferkeard foarheaksel lit de autentikaasje mislearje, net de ûnderhanneling.

Ien klant autentisearret him mei de dielde kaai en in oar wiist dy ôf, wylst de tekens dy't jo plakt hawwe oan beide kanten itselde lykje. It binne wierskynlik deselde tekens; it ferskil is hokker dekodearregel it bestân dêrop tapast. In tekenrige tusken oanhellingstekens wurdt letterlik nommen, in token dat begjint mei 0x wurdt lêzen as heksadesimaal, en in token dat begjint mei 0s wurdt lêzen as Base64. Mar ien fan dy trije skriuwwizen betsjut wat jo bedoelden, dus de reparaasje is meastentiids in konverzje en net in better wachtwurd.

It symptoom wiist op kodearring, net op syfers

As de beide einen ferskillende bytes hâlde, slagget de ûnderhanneling noch altyd en mislearret it bewiis dêrnei. It loch meldt dan in yntegriteits- of HMAC-flater ynstee fan in algoritme-ôfwiking, om't in foarstel keazen is en de autentikaasjestap net oerienkaam. Dy rigel neamt nea de foarm fan it geheim.

De faze is de oanwizing. In flater dy't nei in keazen foarstel komt, betsjut dat beide kanten it oer alles iens wiene behalve oer kaaimateriaal, wylst «gjin foarstel keazen» by belied of syfersets heart. In yntegriteitskontrôle dy't mislearret wylst it wachtwurd goed liket, is it sichtbere gesicht fan in kodearringsôfwiking.

Ien geheim, trije manieren wêrop it bestân it lêze kin

Foar de wearde fan fjouwer bytes key1 binne heksadesimaal en Base64 twa weromkodearrings fan deselde bytes, en allinnich de liedende tekens fertelle de ûntleder hokker fan de twa er hâldt. swanctl-identiteitsbewizen folgje deselde konvinsje, dus in wearde dy't tusken de beide ynterfaces ferpleatst wurdt, behâldt har betsjutting allinnich as har foarheaksel mei reizget.

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

Twa details yn dat blok kostje de measte tiid. Heksadesimale sifers akseptearje beide skriuwwizen, dus 0x6b657931 en 0x6B657931 binne deselde wearde, mar in ûneven oantal tekens wurdt stil ferkeard lêzen ynstee fan ôfwiisd, wat elke byte nei de snij ferpleatst. Base64-opfolning heart by de wearde, dus in tekenrige dy't plakt wurdt sûnder har efterste = tekens dekodearret nei oare bytes ynstee fan lûd te mislearjen.

In profyl dat de wearde ien kear dekodearre hat, hat dy al konvertearre, dus opnij dekodearjen jout oare bytes en in autentikaasjeflater dy't lêst as in ferkeard wachtwurd. Oanhellingstekens binne de feilige rjochting foar alles twifelich, om't de ynhâld letterlik is sels as dy mei in kodearringsmarker begjint.

Wêr't de Base64-tekst wei komt

Profylexporten en leveransiersportalen jouwe de kaai faak al kodearre, meastentiids yn in gegevensfjild dat nea bedoeld wie om mei de hân ynteepje te wurden. Of pak dy wearde út en bewarje de dekodearre tekst tusken oanhellingstekens, of lit it kodearre mei de marker foar. Fan beide de helte dwaan is wat it brekt. Beide paden wurkje allinnich as de hiele wearde it kopiearjen oerlibbet.

Beide rjochtingen binne ien opdracht elk, en it is de muoite wurdich se yn it ticket te hâlden as de krekte operaasje dy't de bewarre wearde makke hat. Fier se yn dizze folchoarder út:

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

Kodearre tekst plakke as wie it gewoan is de djoere flater. It bestân hasht de tekens krekt sa't se skreaun binne, de ôflate kaai komt sawat in tredde langer út as dy't de partner berekkene hat, en elke poging mislearret itselde sûnder warskôging, om't de ûntleder de regel folge dy't him jûn wie.

Befêstigje hokker bytes elk partner eins brûkt

Lês earst it byld fan de daemon fan de ferbining en dêrnei it autentikaasjeresultaat, ynstee fan in oarsaak te rieden út 'e flatertekenrige. It fergelykjen fan de bewarre lingte is in flugge redelikenskontrôle, om't kodearre tekst langer is as de bytes dy't er fertsjintwurdiget. Befêstigje dan hokker identiteitsrigel oerienkaam, om't in korrekt geheim ûnder de ferkearde partner itselde mislearret as in ferkeard. De folchoarder fan 'e rigels beslist dat: de earste oerienkomst wint, dus in brede %any-rigel tichtby de top ferfangt stil de spesifike rigel dy't jo krekt bewurke hawwe.

Laad opnij ynstee fan opnij te starten as it bestân goed is. ipsec rereadsecrets ferfarsket de kopy fan 'e IKE-daemon, en in swanctl-opsetsel laadt identiteitsbewizen fia syn eigen opdracht. In opnij starten smyt elke fêstige assosjaasje fuort en ferneatiget de fergeliking dy't jo besochten te meitsjen.

Gjin fan dizze kontrôles freget it geheim bleat te lizzen. In lingte, in identiteitsselektor en in rigelposysje ferklearje de measte flaters fan dit soart foardat immen in heksdump nedich hat.

Feroarje it bestân sûnder it resultaat te ferbergjen

Behein it bestân ta it akkount fan 'e daemon, en hâld libbene geheims boppe tickets, chat en skermôfbyldings, om't in plakte kaai in lek is en gjin diagnoaze. It oerlibbet ek it ynsidint dat it makke hat.

Test fan in klant waans konfiguraasje jo beheare, befêstigje dat autentikaasje slagget, en befêstigje dan dat de tunnel ferkear draacht. In werladen dat de hânskodding reparearret wylst de rûteleasing brutsen bliuwt, is in oar probleem, en it wurdt sichtber sadree't it geheim ophâldt te bewegen.

Relatearre artikelen