0x alebo 0s? Ako čítať formát PSK v ipsec.secrets

Jeden klient sa autentizuje zdieľaným kľúčom a druhý ho odmieta, hoci znaky, ktoré ste vložili, vyzerajú na oboch stranách rovnako. Pravdepodobne ide o tie isté znaky; rozdiel je v tom, aké pravidlo dekódovania na ne súbor uplatní. Reťazec v úvodzovkách sa berie doslovne, token začínajúci na 0x sa číta ako hexadecimálny a token začínajúci na 0s sa číta ako Base64. Len jeden z tých troch zápisov znamená to, čo ste zamýšľali, takže opravou je zvyčajne prevod, nie lepšie heslo.

Príznak ukazuje na kódovanie, nie na šifry

Keď obe strany držia rôzne bajty, vyjednávanie napriek tomu uspeje a dôkaz potom zlyhá. Protokol potom hlási zlyhanie integrity alebo HMAC, nie nezhodu algoritmu, pretože návrh bol vybraný a krok autentizácie nesúhlasil. Ten riadok nikdy neuvádza podobu tajomstva.

Fáza je stopa. Zlyhanie, ktoré príde po vybranom návrhu, znamená, že sa obe strany zhodli na všetkom okrem kľúčového materiálu, zatiaľ čo „žiadny návrh nevybraný“ patrí politike alebo sadám šifier. Kontrola integrity, ktorá zlyhá, keď heslo vyzerá správne, je viditeľnou tvárou nezhody v kódovaní.

Jedno tajomstvo, tri spôsoby, ako ho súbor môže prečítať

Pre hodnotu zo štyroch bajtov key1 sú hexadecimálny zápis a Base64 dve prekódovania rovnakých bajtov a iba úvodné znaky hovoria parseru, ktoré z nich drží. Prihlasovacie údaje swanctl sa riadia rovnakou konvenciou, takže hodnota prenesená medzi oboma rozhraniami si zachová význam len vtedy, keď jej prefix cestuje s ňou.

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

Dva detaily v tom bloku stoja najviac času. Hexadecimálne číslice prijímajú obe veľkosti písmen, takže 0x6b657931 a 0x6B657931 sú rovnaká hodnota, ale nepárny počet znakov sa ticho prečíta nesprávne, namiesto aby bol odmietnutý, čo posunie každý bajt za miestom rezu. Zarovnanie Base64 patrí k hodnote, takže reťazec vložený bez svojich koncových znakov = sa dekóduje na iné bajty, namiesto aby hlasno zlyhal.

Profil, ktorý hodnotu raz dekódoval, ju už previedol, takže opätovné dekódovanie dáva iné bajty a zlyhanie autentizácie, ktoré vyzerá ako nesprávne heslo. Úvodzovky sú bezpečný smer pre čokoľvek nejednoznačné, pretože obsah je doslovný, aj keď začína značkou kódovania.

Odkiaľ pochádza text Base64

Exporty profilov a portály dodávateľov často odovzdávajú kľúč už zakódovaný, zvyčajne v dátovom poli, ktoré nebolo nikdy určené na ručné písanie. Buď tú hodnotu rozbaľte a uložte dekódovaný text v úvodzovkách, alebo ju nechajte zakódovanú so značkou vpredu. Robiť polovicu z každého je to, čo to pokazí. Obe cesty fungujú len vtedy, keď celá hodnota prežije kopírovanie.

Oba smery sú jeden príkaz, a vyplatí sa ich v tickete ponechať ako presnú operáciu, ktorá uloženú hodnotu vytvorila. Spustite ich v tomto poradí:

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

Vložiť zakódovaný text, akoby bol obyčajný, je drahá chyba. Súbor hashuje znaky presne tak, ako sú napísané, odvodený kľúč vyjde približne o tretinu dlhší ako ten, ktorý vypočítal partner, a každý pokus zlyhá rovnako bez varovania, pretože parser poslúchol pravidlo, ktoré dostal.

Overte, ktoré bajty každý partner skutočne používa

Najprv si prečítajte, ako spojenie vidí démon, a potom výsledok autentizácie, namiesto toho, aby ste príčinu hádali z textu chyby. Porovnanie uloženej dĺžky je rýchla rozumnostná kontrola, pretože zakódovaný text je dlhší ako bajty, ktoré predstavuje. Potom overte, ktorý riadok identity zodpovedal, pretože správne tajomstvo uložené pod nesprávnym partnerom zlyhá rovnako ako nesprávne. Rozhoduje poradie riadkov: prvá zhoda vyhráva, takže široký riadok %any blízko začiatku ticho nahradí konkrétny riadok, ktorý ste práve upravili.

Keď je súbor správny, znovu ho načítajte, namiesto aby ste službu restartovali. ipsec rereadsecrets obnoví kópiu démona IKE a inštalácia so swanctl načítava prihlasovacie údaje vlastným príkazom. Reštart zahodí každé nadviazané spojenie a zničí porovnanie, ktoré ste sa snažili urobiť.

Žiadna z týchto kontrol nevyžaduje odhalenie tajomstva. Dĺžka, selektor identity a pozícia riadku vysvetlia väčšinu takýchto zlyhaní skôr, než niekto potrebuje hexadecimálny výpis.

Zmeňte súbor bez toho, aby ste skryli výsledok

Obmedzte súbor na účet démona a živé tajomstvá držte mimo ticketov, chatu a snímok obrazovky, pretože vložený kľúč je únik, nie diagnostika. Prežije aj incident, ktorý ho vytvoril.

Testujte z klienta, ktorého konfiguráciu ovládate, overte, že autentizácia uspeje, a potom overte, že tunel prenáša prevádzku. Opätovné načítanie, ktoré opraví handshake, zatiaľ čo smerovanie zostane rozbité, je iný problém a ukáže sa hneď, ako sa tajomstvo prestane hýbať.