Výměna klíčů, opětovné připojení, nebo opětovná autentizace: co potřebujete?

Relace, která běží hodiny, nezachová stejné klíče navěky, a je to záměr. Tři různé události se popisují jako rotace klíčů: nový materiál relace pod existující asociací, úplné přestavění spojení a zopakování kontroly identity. Každá má jiný spouštěč, jinou cenu a jiný podpis selhání. Zvolíte-li špatnou, oprava buď nic neudělá, nebo tunel bez důvodu shodí.

Rozhodnutí závisí na tom, která vrstva skutečně vypršela.

Tři operace, kterým se říká rotace

Výměna klíčů vytváří nové provozní klíče v rámci existujícího řídicího vztahu pomocí mechanismu, který protokol definuje. IKEv2 to dělá novou podřízenou bezpečnostní asociací, TLS 1.3 zprávou o aktualizaci klíče a WireGuard novým handshake, jakmile dosáhne svých časových limitů nebo limitů počtu zpráv. Adresy tunelu a autentizovaná identita zůstávají tam, kde byly.

Opětovné připojení zahodí spojení a postaví ho znovu od začátku, což zopakuje přidělení adres, instalaci tras i veškeré vyjednávání, které provedl první pokus.

Opětovná autentizace opakuje samotný důkaz identity, což může zahrnovat přihlašovací údaj, certifikát nebo druhý faktor. Může proběhnout s opětovným připojením i bez něj, podle produktu.

Čeho si uživatelé při obnově všimnou

Výměna klíčů by měla být téměř neviditelná. Identifikátory asociace se mění, čítače se mohou resetovat a aplikace si drží své sockety; krátká pauza v jednom směru je při výměně normální. Nový identifikátor ve výpisu stavu není důkazem závady. Řádek protokolu, který následuje po výměně, vám řekne, zda skončila.

Skutečný výpadek při obnově ukazuje na konkrétní místo. Neshoda návrhu, vypršelý přihlašovací údaj nebo změna cesty každý vytváří jiný řádek protokolu a jen jeden z nich se opravuje úpravou životností.

Kde se tři operace v praxi rozcházejí

Pokud vypršel jen klíčový materiál, vyměňte klíč. Pokud se změnila adresa protějšku, trasa nebo vazba NAT a pakety už nedorazí, připojte se znovu. Pokud organizace vyžaduje pravidelnou kontrolu identity, jde o opětovnou autentizaci a žádné ladění životností ji nenahradí.

Výchozí hodnoty protokolů obvykle obsahují správnou odpověď. WireGuard mění klíče po časovém prahu a prahu objemu dat bez zásahu uživatele; životnosti IKEv2 se vyjednávají pro každou podřízenou asociaci; tunely na bázi TLS rotují klíče uvnitř existující relace. Zvyšování životností, aby se předešlo opakované chybě, selhání jen odkládá a prodlužuje expozici, pokud je klíč kompromitován.

Pro dlouhé relace je důležitá jedna výhrada: samotná četnost nevytváří dopřednou utajenost. Tato vlastnost závisí na tom, jak relační klíče souvisejí s dlouhodobými tajemstvími a zda se staré klíče ničí, což je otázka návrhu a implementace, nikoli nastavení.

Zvolte výchozí hodnoty a pak zaznamenejte fázi

Ponechte výchozí hodnoty dodavatele, pokud dokumentovaný požadavek neříká jinak, a měníte-li životnosti, změňte je na obou stranách. Potom zaznamenejte, do které fáze se každá událost dostala, aby se příští výskyt dal zkontrolovat proti stejnému bodu handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Po opravě proveďte řízenou obnovu a pošlete čerstvý provoz aplikací přes novou asociaci. Tunel, který hlásí navázání, ale nic nepředává, je selhání, kvůli kterému tato kontrola existuje.