Předsdílený klíč IPsec: bajty za řetězcem, který jste napsali

Dva správci porovnají tajemství na obrazovce, shodnou se, že je stejné, a tunel přesto neprojde autentizací. Řetězec, který porovnali, není hodnota, kterou kterýkoli konec předává do odvození klíče. Mezi znaky, které vidíte, a bajty, které protokol hashuje, je typ pole, textové kódování, editor a schránka a kterýkoli ze čtyř může změnit vstup, aniž by změnil jeho vzhled. Porovnejte bajty a neshoda se obvykle objeví během sekund.

Co brána s řetězcem dělá

Předsdílený klíč se nepřenáší po drátě a neporovnává. Každý konec předá svou místní kopii do odvození klíče pro výměnu IKE a výsledné autentizační datové části buď projdou ověřením, nebo ne. Takový návrh znamená, že obě kopie musí být bajtově totožné, nikoli vizuálně podobné, a také znamená, že selhání se hlásí ve fázi autentizace, nikoli jako zpráva o nesprávném heslu.

Užitečná otázka tedy nikdy není „vypadají stejně“, ale „jakou přesnou posloupnost bajtů každá implementace hashuje“.

Odkud se berou bajty navíc

Koncový nový řádek je klasický viník a skrývá se na očích, protože většina editorů ho při ukládání souboru neviditelně přidá. Úvodní nebo koncová mezera vložená z chatovacího okna dělá totéž, stejně jako typografická uvozovka, kterou textový procesor nahradil rovnou. Nic z toho nemění vizuální srovnání, které provádí člověk.

Porovnávejte nástrojem, který ukazuje bajty, ne glyfy. printf '%s' "$PSK" | xxd | tail -2 vypíše konec hodnoty v šestnáctkové soustavě, kde je zatoulaný 0a nebo 20 zřejmý. Udělejte to na obou koncích a porovnejte oba výpisy vedle sebe. Dělejte to na vygenerovaném testovacím materiálu, ne na produkčním tajemství, které pak necháte v historii shellu.

Kódované není šifrované

Exporty konfigurace často nesou tajemství v základním kódování, někdy se zlomy řádků každých šedesát nebo sedmdesát šest znaků a někdy s doplněním. Pokud jeden konec očekává dekódované bajty a vy vložíte kódovaný text, neposlali jste jiné heslo, poslali jste mnohem delší heslo složené z tisknutelných znaků. Base64 neposkytuje žádnou důvěrnost, a proto se kódované tajemství nikdy nesmí vkládat na fórum kvůli druhému názoru.

Apple slovníček IPSec je užitečný příklad toho, že na typu záleží: dokumentuje SharedSecret jako data pro metodu autentizace sdíleným tajemstvím v datových částech L2TP a Cisco IPsec. To je konkrétní vlastnost v konkrétní datové části, ne obecné textové pole, které lze znovu použít pro jiný protokol, jenž náhodou žádá tajemství.

Tvrzený limit patří jedné kombinaci

Staré zprávy o stropu třiceti dvou znaků u jednoho klienta Apple jsou skutečné zprávy o jedné verzi klienta, protokolu a tvaru profilu. Nejsou univerzálním limitem pro každou platformu Apple, každého poskytovatele a každý protokol. Zkontrolujte verzi, typ datové části a požadavek brány společně, poté testujte na schváleném uspořádání, místo abyste usuzovali z vlákna. Zapište otestovanou kombinaci do záznamu o změně, protože jinak se další člověk bude odvolávat na stejné vlákno s větší jistotou, než si zaslouží.

Pokud limit skutečně platí, odpovědí je podporovaný návrh přihlašovacích údajů, který se do něj vejde, nikoli zkrácená verze silného tajemství. Zkrácení produkčního klíče, aby vyhověl odhadovanému limitu, trvale snižuje jeho sílu a vytváří systém, jehož dokumentace už neodpovídá jeho zabezpečení.

Opravte reprezentaci, ne sílu

Když autentizace selže poté, co je reprezentace potvrzena, přečtěte si efektivní zásadu ve fázi autentizace: která metoda se vyjednává, která identita protějšku se očekává a zda brána odpovídá spojení, které si myslíte. Postupně slabší odhady nejsou diagnostika, jsou to pomalé snižování úrovně s přiloženým tiketem podpory.

Pokud požadované přihlašovací údaje nemohou splnit standard organizace, změňte návrh na takový, který ho splnit může. Sdílené tajemství s dostatečnou entropií, vygenerované jednou, uložené ve spravovaném poli a nikdy nezveřejněné, je naprosto dobrá odpověď; jeho kratší verze nikoli.