Prečo AES-256 neopisuje šifrovaciu sadu VPN
Sada plní štyri úlohy: hromadné šifrovanie, integrita, ustanovenie kľúčov a overenie protistrany. Názov šifry pokrýva len jednu z nich, na jednej vrstve.
Spýtajte sa, aké šifrovanie VPN používa, a odpoveď zvyčajne príde ako jedno slovo: AES-256, alebo ChaCha20, alebo možno WireGuard. Tá odpoveď pomenúva jednu súčasť jednej vrstvy, kým to, čo spojenie skutočne chráni, je sada algoritmov plniacich štyri rôzne úlohy. Zámena súčasti s usporiadaním je v týchto rozhovoroch najčastejšou chybou a vytvára porovnania, ktoré nemožno rozhodnúť.
Štyri úlohy v jednom spojení
Hromadné šifrovanie mení otvorený text na šifrovaný pre dátový kanál a jeho kľúč sa odvodzuje, nie prenáša. Ochrana integrity odhaľuje zmenu, čo je samostatná úloha, aj keď jedna konštrukcia robí oboje. Ustanovenie kľúčov vytvára spoločný prevádzkový materiál a overenie protistrany rozhoduje, kto je na druhom konci. Ak chýba čokoľvek z toho, spojenie nie je bezpečné, nech je zvyšná časť akokoľvek silná.
Niektoré návrhy spájajú dve úlohy do jednej. AES-GCM a ChaCha20-Poly1305 sú autentizované šifrovacie konštrukcie, takže dôvernosť a integrita prichádzajú spolu; AES-CBC nie je, potrebuje samostatný kód na overenie správy s vlastným kľúčom. Preto čítanie návrhu ako vreca nezávislých čísel zle číta tie, ktoré boli navrhnuté ako dvojice.
Úlohy ležia aj na rôznych vrstvách, a preto to isté slovo môže v dvoch produktoch znamenať niečo iné. Bloková šifra v ESP a bloková šifra v TLS sú ten istý primitív v rôznych rokovaniach s rôznymi požiadavkami. Preto citovanie primitívu bez jeho režimu a vrstvy môže byť horšie než necitovať nič.
Prečo názov šifry takmer nič nehovorí
Vezmite frázu AES-256 na chvíľu vážne: označuje blokovú šifru a veľkosť kľúča. Nehovorí nič o režime prevádzky, o tom, či je zabezpečená integrita, ako boli kľúče ustanovené alebo ako bola protistrana overená. Dva produkty môžu oba inzerovať AES-256 a líšiť sa vo všetkom ostatnom, vrátane jedného s neautentizovaným režimom a druhého s režimom AEAD a modernou výmenou kľúčov.
TLS 1.3 zaviedol toto oddelenie do štandardu, čo je užitočná oprava pre každého, kto sa učil starší slovník. Jeho šifrové sady pomenúvajú len AEAD a hash, kým skupiny na výmenu kľúčov a algoritmy podpisu sa dohadujú ako samostatné parametre. Preto názov sady TLS 1.3 nie je porovnateľný s názvom sady TLS 1.2 za rovnakých podmienok, hoci sa oba objavujú v tom istom poli konfiguračného súboru. Audítor, ktorý oba reťazce porovná priamo, vyvodí záver, ktorý protokol nepodporuje. Prečítajte si aj dohodnutú skupinu a parametre podpisu, inak je porovnanie neúplné.
WireGuard volí opačnú cestu a rokovanie takmer úplne odstraňuje: protokol určuje pevnú sadu algoritmov, takže dve implementácie buď spolupracujú, alebo nie. Je to legitímna dizajnová voľba a tiež to znamená, že otázka, akú sadu WireGuard dohaduje, nemá odpoveď hodnú porovnania. Ak ho auditujete, prečítajte si špecifikáciu raz a potom auditujte správu kľúčov okolo nej namiesto rokovania.
Vrstva určuje slovník
Nasadenie IPsec dohaduje dvakrát: návrh IKE pre riadiaci kanál a transformáciu ESP pre dáta, a oba sa môžu legitímne líšiť. Čítať prvý a predpokladať, že opisuje druhý, je častým zdrojom zmätku pri audite, pretože konfiguračný súbor spomína oba a zaujímavý je druhý.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Názov dostupný v jednej knižnici nie je automaticky implementovaný pre inú dátovú cestu. Preto je tvrdenie, že náš produkt podporuje AES-256, slabšie, než znie, a preto sa problém interoperability zvyčajne rieši nájdením udržiavaného prieniku, nie zapnutím každého starého algoritmu na oboch stranách.
Špecifikácia TLS 1.3 je najjasnejší publikovaný príklad tohto oddelenia, pretože definuje sadu ako dvojicu a zvyšok presúva do vlastného rokovania. Keď je tento tvar známy, návrh IPsec a jediná pevná sada WireGuard sa čítajú ako varianty tej istej myšlienky.
Prečítajte dohodnutý výsledok a potom prestaňte
Nakonfigurovaný návrh nie je dôkazom toho, čo si dvaja partneri vybrali. Živá relácia nesie odpoveď a každá bežná implementácia ju môže nahlásiť bez zachytávania paketov.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show
Vo výstupe čítajte zvolené algoritmy, nie ponúkaný zoznam. Ak je odpoveď slabšia, než politika zamýšľala, oprava patrí do konfigurácie návrhu na jednej strane, a nesúlad sa v moderných implementáciách zvyčajne prejaví ako neúspešné rokovanie, nie ako tiché zníženie.
Potom si pamätajte, čo sada nepokrýva. Trasy, oprávnenia aplikácií, zaznamenávanie a uchovávanie sú samostatné rozhodnutia s vlastným preskúmaním a kompatibilné kryptografické usporiadanie o nich nič nehovorí. Diskusia o šifre stojí za to, ale odpovedá na užšiu otázku, než akú väčšina ľudí skutočne kladie.
Držte slovník presný a argument sa skráti. Sada je súbor úloh na vrstve, šifra je jedna súčasť a dohodnutý výsledok je jediné, čo opisuje spojenie, ktoré skutočne máte. Všetko ostatné v porovnaní je dekorácia.