0x, nebo 0s? Jak číst formát PSK v ipsec.secrets

Jeden klient se autentizuje sdíleným klíčem a druhý ho odmítá, přitom znaky, které jste vložili, vypadají na obou stranách stejně. Pravděpodobně jde o stejné znaky; rozdíl je v tom, jaké pravidlo dekódování na ně soubor uplatní. Řetězec v uvozovkách se bere doslovně, token začínající na 0x se čte jako hexadecimální a token začínající na 0s se čte jako Base64. Jen jeden z těch tří zápisů znamená to, co jste zamýšleli, takže opravou je obvykle převod, ne lepší heslo.

Příznak ukazuje na kódování, ne na šifry

Když obě strany drží různé bajty, vyjednávání přesto uspěje a důkaz poté selže. Protokol pak hlásí selhání integrity nebo HMAC, ne neshodu algoritmu, protože návrh byl vybrán a krok autentizace nesouhlasil. Ten řádek nikdy nezmiňuje podobu tajemství.

Fáze je stopa. Selhání, které přijde po vybraném návrhu, znamená, že se obě strany shodly na všem kromě klíčového materiálu, zatímco „žádný návrh nevybrán“ patří politice nebo sadám šifer. Kontrola integrity, která selže, když heslo vypadá správně, je viditelnou tváří neshody v kódování.

Jedno tajemství, tři způsoby, jak ho soubor může přečíst

Pro hodnotu o čtyřech bajtech key1 jsou hexadecimální zápis a Base64 dvě překódování stejných bajtů a jen úvodní znaky říkají parseru, které z nich drží. Přihlašovací údaje swanctl se řídí stejnou konvencí, takže hodnota přenesená mezi oběma rozhraními si zachová význam jen tehdy, když její prefix cestuje s ní.

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 stojí nejvíc času. Hexadecimální číslice přijímají obě velikosti písmen, takže 0x6b657931 a 0x6B657931 jsou stejná hodnota, ale lichý počet znaků se tiše přečte špatně, místo aby byl odmítnut, což posune každý bajt za místem řezu. Zarovnání Base64 patří k hodnotě, takže řetězec vložený bez svých koncových znaků = se dekóduje na jiné bajty, místo aby hlasitě selhal.

Profil, který hodnotu jednou dekódoval, ji už převedl, takže opětovné dekódování dává jiné bajty a selhání autentizace, které vypadá jako špatné heslo. Uvozovky jsou bezpečný směr pro cokoli nejednoznačného, protože obsah je doslovný, i když začíná značkou kódování.

Odkud pochází text Base64

Exporty profilů a portály dodavatelů často předávají klíč už zakódovaný, obvykle v datovém poli, které nikdy nebylo určeno k ručnímu psaní. Buď tu hodnotu rozbalte a uložte dekódovaný text v uvozovkách, nebo ji ponechte zakódovanou se značkou vpředu. Dělat půlku jednoho a půlku druhého je to, co to rozbíjí. Obě cesty fungují jen tehdy, když celá hodnota přežije kopírování.

Oba směry jsou jeden příkaz, a vyplatí se je v ticketu ponechat jako přesnou operaci, která uloženou hodnotu vytvořila. Spusťte je v tomto pořadí:

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

Vložit zakódovaný text, jako by byl obyčejný, je drahá chyba. Soubor hashuje znaky přesně tak, jak jsou napsané, odvozený klíč vyjde zhruba o třetinu delší než ten, který spočítal protějšek, a každý pokus selže stejně bez varování, protože parser poslechl pravidlo, které dostal.

Ověřte, které bajty každý protějšek skutečně používá

Nejprve si přečtěte, jak spojení vidí démon, a potom výsledek autentizace, místo abyste příčinu hádali z textu chyby. Porovnání uložené délky je rychlá rozumnostní kontrola, protože zakódovaný text je delší než bajty, které představuje. Pak ověřte, který řádek identity odpovídal, protože správné tajemství uložené pod špatným protějškem selže stejně jako špatné. Rozhoduje pořadí řádků: první shoda vyhrává, takže široký řádek %any blízko začátku tiše nahradí konkrétní řádek, který jste právě upravili.

Jakmile je soubor správný, znovu ho načtěte, místo abyste službu restartovali. ipsec rereadsecrets obnoví kopii démona IKE a instalace se swanctl načítá přihlašovací údaje vlastním příkazem. Restart zahodí každé navázané spojení a zničí srovnání, které jste se snažili udělat.

Žádná z těchto kontrol nevyžaduje odhalení tajemství. Délka, selektor identity a pozice řádku vysvětlí většinu takových selhání dřív, než někdo potřebuje hexadecimální výpis.

Změňte soubor, aniž byste skryli výsledek

Omezte soubor na účet démona a živá tajemství držte mimo tickety, chat a snímky obrazovky, protože vložený klíč je únik, ne diagnostika. Také přežije incident, který ho vytvořil.

Testujte z klienta, jehož konfiguraci ovládáte, ověřte, že autentizace uspěje, a pak ověřte, že tunel přenáší provoz. Opětovné načtení, které opraví handshake, zatímco směrování zůstane rozbité, je jiný problém a ukáže se, jakmile se tajemství přestane měnit.