Proč AES-256 nepopisuje šifrovací sadu VPN

Zeptejte se, jaké šifrování VPN používá, a odpověď obvykle přijde jako jedno slovo: AES-256, nebo ChaCha20, nebo možná WireGuard. Taková odpověď pojmenovává jednu součást jedné vrstvy, zatímco to, co spojení skutečně chrání, je sada algoritmů plnících čtyři různé role. Záměna součásti s uspořádáním je v těchto rozhovorech nejčastější chybou a vytváří srovnání, která nelze rozhodnout.

Čtyři úlohy v jednom spojení

Hromadné šifrování mění otevřený text na šifrovaný pro datový kanál a jeho klíč se odvozuje, nikoli přenáší. Ochrana integrity odhaluje změnu, což je samostatná úloha, i když jediná konstrukce dělá obojí. Ustanovení klíčů vytváří sdílený provozní materiál a ověření protistrany rozhoduje, kdo je na druhém konci. Chybí-li kterákoli z nich, spojení není bezpečné, ať je zbývající část jakkoli silná.

Některé návrhy slučují dvě role do jedné. AES-GCM a ChaCha20-Poly1305 jsou autentizované šifrovací konstrukce, takže důvěrnost a integrita přicházejí společně; AES-CBC ne, ten potřebuje samostatný kód pro ověření zprávy s vlastním klíčem. Číst návrh jako pytel nezávislých čísel proto špatně čte ty, které byly navrženy jako dvojice.

Role také leží v různých vrstvách, a proto totéž slovo může ve dvou produktech znamenat různé věci. Bloková šifra v ESP a bloková šifra v TLS jsou stejný primitiv v různých vyjednáváních s různými požadavky. Proto může být citování primitivu bez jeho módu a vrstvy horší než necitovat nic.

Proč název šifry neříká téměř nic

Vezměte frázi AES-256 na chvíli vážně: označuje blokovou šifru a velikost klíče. Neříká nic o režimu provozu, zda je zajištěna integrita, jak byly klíče ustanoveny nebo jak byla protistrana ověřena. Dva produkty mohou oba inzerovat AES-256 a lišit se ve všem ostatním, včetně jednoho s neautentizovaným režimem a druhého s režimem AEAD a moderní výměnou klíčů.

TLS 1.3 zavedl toto oddělení do standardu, což je užitečná oprava pro každého, kdo se učil starší slovník. Jeho šifrové sady pojmenovávají jen AEAD a hash, zatímco skupiny pro výměnu klíčů a algoritmy podpisu se vyjednávají jako samostatné parametry. Název sady TLS 1.3 proto není srovnatelný s názvem sady TLS 1.2 za stejných podmínek, i když se oba objevují ve stejném poli konfiguračního souboru. Auditor, který oba řetězce porovná přímo, vyvodí závěr, který protokol nepodporuje. Přečtěte si i vyjednanou skupinu a parametry podpisu, jinak je srovnání neúplné.

WireGuard volí opačný přístup a vyjednávání téměř úplně odstraňuje: protokol určuje pevnou sadu algoritmů, takže dvě implementace buď spolupracují, nebo ne. Je to legitimní designová volba a také to znamená, že otázka, jakou sadu WireGuard vyjednává, nemá odpověď hodnou srovnání. Pokud ho auditujete, přečtěte specifikaci jednou a pak auditujte správu klíčů kolem ní místo vyjednávání.

Vrstva určuje slovník

Nasazení IPsec vyjednává dvakrát: návrh IKE pro řídicí kanál a transformaci ESP pro data, a oba se mohou legitimně lišit. Číst první a předpokládat, že popisuje druhé, je častý zdroj zmatku při auditu, protože konfigurační soubor zmiňuje oba a zajímavý je druhý.

Název dostupný v jedné knihovně není automaticky implementován pro jinou datovou cestu. Proto je tvrzení, že náš produkt podporuje AES-256, slabší, než zní, a proto se problém interoperability obvykle řeší nalezením udržovaného průniku, nikoli zapnutím každého starého algoritmu na obou stranách.

Specifikace TLS 1.3 je nejjasnější publikovaný příklad tohoto oddělení, protože definuje sadu jako dvojici a zbytek přesouvá do vlastního vyjednávání. Jakmile je tento tvar známý, návrh IPsec a jediná pevná sada WireGuard se čtou jako varianty téže myšlenky.

Přečtěte vyjednaný výsledek a pak přestaňte

Nakonfigurovaný návrh není důkazem toho, co dva partneři vybrali. Živá relace nese odpověď a každá běžná implementace ji může hlásit bez zachytávání paketů.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Ve výstupu čtěte zvolené algoritmy, nikoli nabízený seznam. Je-li odpověď slabší, než politika zamýšlela, oprava patří do konfigurace návrhu na jedné straně, a nesoulad se v moderních implementacích obvykle projeví jako neúspěšné vyjednávání, nikoli jako tiché snížení.

Pak si pamatujte, co sada nepokrývá. Trasy, oprávnění aplikací, protokolování a uchovávání jsou samostatná rozhodnutí s vlastní revizí a kompatibilní kryptografické uspořádání o nich nic neříká. Diskuse o šifře stojí za to, ale odpovídá na užší otázku, než jakou většina lidí skutečně klade.

Držte slovník přesný a argument se zkrátí. Sada je soubor rolí ve vrstvě, šifra je jedna součást a vyjednaný výsledek je jediné, co popisuje spojení, které skutečně máte. Všechno ostatní ve srovnání je dekorace.