Šifry Windows a strongSwan: slaďte správnou vrstvu

Obě strany říkají AES-128 a tunel se přesto odmítá sestavit. CBC a GCM jsou různé transformace, které náhodou sdílejí stejnou délku klíče, a klient nabízející jednu neuspokojí bránu, která přijímá jen druhou. Slovo AES popisuje rodinu, ne dohodu.

Existuje i druhá osa a právě ta vytváří matoucí chyby.

Dvě vrstvy, dva nezávislé seznamy

IKE chrání samotné vyjednávání, zatímco podřízená asociace chrání provoz, na kterém vám skutečně záleží. Windows vystavuje první jako metodu šifrování a metodu integrity a druhé jako konstanty transformace šifry a autentizace. Tato pole nejsou vzájemnými aliasy a hodnota platná v jednom může být v druhém nesmyslná nebo chybná. Čtení profilu s tímto rozdělením na mysli odstraní většinu zmatku.

Praktickým důsledkem je, že můžete mít zcela přijatelnou politiku výměny klíčů a politiku datového kanálu, kterou protějšek nepřijme. Jeden seznam vyjednává; druhý chrání pakety. Změna hodnoty v prvním nemá na druhý žádný vliv, ať už oba v konfiguračním dialogu vypadají jakkoli podobně.

Než je porovnáte s bránou, zapište oba seznamy. Porovnání z paměti je způsob, jak se jedno pole upraví dvakrát a druhé nikdy. Mějte konzoli brány otevřenou vedle profilu.

Čtěte chybu vedle návrhů

Fáze, která selhala, vám řekne, který seznam prozkoumat. Odmítnutí během počáteční výměny klíčů je problém návrhu IKE, a nastává dříve, než existuje jakákoli podřízená asociace. Selhání při vyjednávání asociace chráněného provozu je problém návrhu ESP a výměna klíčů už uspěla. Obecná zpráva o shodě politiky od klienta nepojmenuje ani jednu fázi, proto je užitečný vlastní pohled brány.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Porovnejte přijatý návrh, nakonfigurovaný návrh a vybraný pro tento jediný pokus. Záleží zde na třech různých seznamech a jen poslední popisuje, co se skutečně použilo. Uveďte jej v tiketu doslovně, místo abyste jej shrnovali.

Držte CBC a GCM jako samostatné alternativy

Brána, které je záměrně dovoleno přijmout kteroukoli rodinu, potřebuje dva návrhy, ne jeden. V strongSwan odděluje alternativy čárka a pomlčka spojuje komponenty jedné sady. Spojení obou rodin pomlčkami vytvoří jeden nemožný návrh místo dvou přijatelných.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

První alternativa nese autentizované šifrování a stále uvádí pseudonáhodnou funkci, protože odvození klíče ji potřebuje, i když integrita pochází ze šifry. Druhá alternativa je klasické šifrování se samostatným algoritmem integrity. Obě zůstávají závislé na tom, co podporuje načtená kryptografická implementace.

Návrh ESP není přejmenovaný návrh IKE

Token šifry vypadá v obou seznamech stejně a téměř nic dalšího se nepřenáší. Návrh ESP nemá pseudonáhodnou funkci výměny klíčů a jeho požadavky na integritu a dopředné utajení se obhajují proti politice Windows na druhé straně, místo aby se kopírovaly z řádku IKE. Mechanický překlad jednoho seznamu do druhého vytvoří něco, co projde validací a nikdy nevyjedná.

Vyberte směr a držte se ho. Buď brána zachová politiku pouze GCM a klient nasadí úplnou kompatibilní politiku, nebo brána přijme obě rodiny a klient si ponechá svou stávající sadu. Zapnutí záložní varianty, kterou bezpečnostní politika zakazuje, není oprava, jakkoli rychle chybu odstraní.

Ověřte obě sady a potom obnovu klíče

Potvrďte zvlášť vybranou sadu výměny klíčů a vybranou sadu provozu, protože pocházejí z různých seznamů a mohou uspět nezávisle. Potom nechte proběhnout obnovu klíče a potvrďte ji také. První fungující handshake a selhávající obnova klíče popisují sadu návrhů, která je jen částečně přijatelná.

Uchovejte tento důkaz u změny. Opakované odpojení potřebuje vlastní záznam o neúspěšné výměně, než někdo obviní časovač nebo závadu platformy.