0x vagy 0s? A PSK-formátum értelmezése az ipsec.secrets fájlban

Az egyik kliens sikeresen azonosít a megosztott kulccsal, a másik elutasítja, pedig a beillesztett karakterek mindkét oldalon ugyanúgy néznek ki. Valószínűleg ugyanazok a karakterek; a különbség az, hogy a fájl melyik dekódolási szabályt alkalmazza rájuk. Az idézőjelbe tett sztring szó szerint értendő, a 0x előtaggal kezdődő token hexadecimálisként olvasódik, a 0s előtaggal kezdődő token pedig Base64-ként. Csak ennek a három írásmódnak az egyike jelenti azt, amit szándékozott, ezért a javítás általában átalakítás, nem jobb jelszó.

A tünet a kódolásra mutat, nem a titkosításokra

Amikor a két vég különböző bájtokat tart, a tárgyalás mégis sikerül, és a bizonyíték utána bukik el. A napló ekkor integritás- vagy HMAC-hibát jelent algoritmus-eltérés helyett, mert kiválasztódott egy javaslat, és az azonosítási lépés nem egyezett. Az a sor soha nem említi a titok alakját.

A fázis a nyom. A kiválasztott javaslat után érkező hiba azt jelenti, hogy a két fél mindenben megegyezett a kulcsanyagon kívül, míg a „nincs kiválasztott javaslat” a szabályzathoz vagy a titkosítási készletekhez tartozik. Az integritás-ellenőrzés, amely akkor bukik el, amikor a jelszó helyesnek látszik, a kódolási eltérés látható arca.

Egy titok, három mód, ahogy a fájl olvashatja

A négybájtos key1 értéknél a hexadecimális és a Base64 ugyanazon bájtok két újrakódolása, és csak a kezdő karakterek mondják meg az elemzőnek, melyiket tartja. A swanctl hitelesítő adatai ugyanezt a konvenciót követik, ezért a két felület között átvitt érték csak akkor őrzi meg a jelentését, ha az előtagja vele utazik.

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

Két részlet kerül a legtöbb időbe ebben a blokkban. A hexadecimális számjegyek mindkét írásmódot elfogadják, tehát 0x6b657931 és 0x6B657931 ugyanaz az érték, de a páratlan karakterszámot csendben hibásan olvassa be a rendszer ahelyett, hogy elutasítaná, ami a vágás utáni minden bájtot eltol. A Base64-kitöltés az érték része, ezért a záró = jelek nélkül beillesztett sztring más bájtokká dekódolódik ahelyett, hogy hangosan elbukna.

Az a profil, amely egyszer már dekódolta az értéket, már át is alakította, ezért az újabb dekódolás más bájtokat és rossz jelszóra hasonlító azonosítási hibát eredményez. Bármi kétértelműnél az idézőjel a biztonságos irány, mert a tartalom akkor is szó szerinti, ha kódolási jelöléssel kezdődik.

Honnan származik a Base64-szöveg

A profil-exportok és a szállítói portálok gyakran már kódolva adják át a kulcsot, általában olyan adatmezőben, amelyet soha nem szántak kézi begépelésre. Vagy bontsa ki azt az értéket, és tárolja a dekódolt szöveget idézőjelben, vagy hagyja kódolva, a jelöléssel az elején. Mindkettőből a felét csinálni az, ami elrontja. Mindkét út csak akkor működik, ha a teljes érték túléli a másolást.

Mindkét irány egy-egy parancs, és érdemes a ticketben tartani őket mint a tárolt értéket létrehozó pontos műveletet. Futtassa őket ebben a sorrendben:

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

A kódolt szöveget sima szövegként beilleszteni a drága hiba. A fájl pontosan úgy hasheli a karaktereket, ahogy le vannak írva, a származtatott kulcs nagyjából egyharmaddal hosszabb lesz annál, mint amit a partner kiszámított, és minden kísérlet ugyanúgy elbukik figyelmeztetés nélkül, mert az elemző a kapott szabályt követte.

Erősítse meg, mely bájtokat használja valójában az egyes partnerek

Először a démon kapcsolatra vonatkozó nézetét olvassa el, aztán az azonosítás eredményét, ahelyett hogy a hibaüzenetből találgatna okot. A tárolt hossz összehasonlítása gyors észszerűségi ellenőrzés, mert a kódolt szöveg hosszabb, mint az általa képviselt bájtok. Ezután erősítse meg, melyik identitássor egyezett, mert a rossz partner alá sorolt helyes titok pontosan úgy elbukik, mint egy rossz. A sorok sorrendje dönt erről: az első egyezés nyer, ezért egy széles %any sor a teteje közelében csendben lecseréli az éppen szerkesztett konkrét sort.

Töltse újra ahelyett, hogy újraindítaná, ha a fájl már helyes. ipsec rereadsecrets frissíti az IKE-démon példányát, a swanctl-telepítés pedig a saját parancsával tölti be a hitelesítő adatokat. Az újraindítás minden felépített kapcsolatot eldob, és lerombolja az összehasonlítást, amelyet megpróbált elvégezni.

Egyik ellenőrzés sem igényli a titok felfedését. Egy hossz, egy identitásválasztó és egy sorpozíció megmagyarázza az ilyen hibák többségét, mielőtt bárkinek hexdumpra lenne szüksége.

Módosítsa a fájlt az eredmény elrejtése nélkül

Szűkítse a fájlt a démon fiókjára, és tartsa az élő titkokat a ticketeken, a chaten és a képernyőképeken kívül, mert a beillesztett kulcs szivárgás, nem diagnózis. Továbbá túléli az incidenst, amely létrehozta.

Teszteljen olyan kliensről, amelynek a konfigurációját Ön irányítja, erősítse meg, hogy az azonosítás sikerül, majd erősítse meg, hogy az alagút forgalmat szállít. Az újratöltés, amely rendbe teszi a kézfogást, miközben az útválasztás törött marad, másik probléma, és láthatóvá válik, amint a titok abbahagyja a mozgást.