Miért nem ír le az AES-256 egy VPN-titkosítási csomagot

Kérdezze meg, milyen titkosítást használ egy VPN, és a válasz általában egyetlen szó: AES-256, vagy ChaCha20, vagy esetleg WireGuard. Ez a válasz egy réteg egyetlen összetevőjét nevezi meg, miközben a kapcsolatot valójában négy különböző szerepet betöltő algoritmusegyüttes védi. Az összetevő és az elrendezés összekeverése a leggyakoribb hiba ezekben a beszélgetésekben, és olyan összehasonlításokat szül, amelyeket nem lehet eldönteni.

Négy feladat egy kapcsolaton belül

A tömeges titkosítás sima szöveget rejtjeles szöveggé alakít az adatcsatornán, és a kulcsa származtatással jön létre, nem átvitellel. A sértetlenség védelme változást észlel, ami külön feladat, akkor is, ha egyetlen konstrukció végzi mindkettőt. A kulcsépítés állítja elő a közös forgalmi anyagot, a partner hitelesítése pedig eldönti, ki van a másik végén. Ha bármelyik hiányzik, a kapcsolat nem biztonságos, bármilyen erős is a maradék rész.

Egyes tervek két szerepet vonnak össze. Az AES-GCM és a ChaCha20-Poly1305 hitelesített titkosítási konstrukció, így a bizalmasság és a sértetlenség együtt érkezik; az AES-CBC nem az, és külön üzenethitelesítő kódot igényel saját kulccsal. Ezért a javaslat zsáknyi független számként való olvasása félreolvassa azokat, amelyeket párként terveztek.

A szerepek különböző rétegeken is elhelyezkednek, ezért ugyanaz a szó két termékben mást jelenthet. Az ESP-n belüli blokk-rejtjelező és a TLS-en belüli blokk-rejtjelező ugyanaz a primitív különböző tárgyalásokban, különböző követelményekkel. Ezért egy primitív említése a módja és rétege nélkül rosszabb lehet, mint semmit sem említeni.

Miért mond szinte semmit egy rejtjelező neve

Vegye komolyan egy pillanatra az AES-256 kifejezést: blokk-rejtjelezőt és kulcsméretet jelöl. Semmit sem mond a működési módról, arról, hogy biztosított-e a sértetlenség, arról, hogyan épültek a kulcsok, vagy hogyan hitelesítették a partnert. Két termék egyaránt hirdetheti az AES-256-ot, és minden másban különbözhet, köztük az egyik hitelesítetlen móddal, a másik AEAD-móddal és modern kulcscserével.

A TLS 1.3 bevitte ezt a szétválasztást a szabványba, ami hasznos korrekció mindenkinek, aki a régebbi szókincset tanulta. A rejtjelező csomagjai csak az AEAD-ot és a hash-t nevezik meg, míg a kulcscsere-csoportok és az aláírás-algoritmusok külön paraméterként tárgyalódnak. Ezért a TLS 1.3 csomagnév nem hasonlítható össze a TLS 1.2 csomagnévvel egyenlő feltételek mellett, bár mindkettő ugyanabban a mezőben jelenik meg egy konfigurációs fájlban. Az a vizsgáló, aki a két karakterláncot közvetlenül összehasonlítja, olyan következtetésre jut, amelyet a protokoll nem támaszt alá. Olvassa el a tárgyalt csoportot és az aláírás-paramétereket is, különben az összehasonlítás hiányos.

A WireGuard az ellenkező utat választja, és a tárgyalást szinte teljesen megszünteti: a protokoll rögzített algoritmusegyüttest ír elő, így két megvalósítás vagy együttműködik, vagy nem. Ez jogos tervezési döntés, és azt is jelenti, hogy arra a kérdésre, milyen csomagot tárgyal a WireGuard, nincs összehasonlításra érdemes válasz. Ha vizsgálja, olvassa el egyszer a specifikációt, majd vizsgálja a körülötte lévő kulcskezelést a tárgyalás helyett.

A réteg dönti el a szókincset

Az IPsec-telepítés kétszer tárgyal: IKE-javaslatot a vezérlőcsatornára és ESP-átalakítást az adatokra, és a kettő jogosan eltérhet. Az első olvasása és annak feltételezése, hogy a másodikat írja le, gyakori zavarforrás a vizsgálat során, mert a konfigurációs fájl mindkettőt említi, és az érdekes a második.

Az egyik könyvtárban elérhető név nem valósul meg automatikusan egy másik adatútvonalhoz. Ezért az az állítás, hogy termékünk támogatja az AES-256-ot, gyengébb, mint amilyennek hangzik, és ezért az együttműködési problémát általában a fenntartott metszet megtalálásával oldják meg, nem pedig az összes régi algoritmus engedélyezésével mindkét oldalon.

A TLS 1.3 specifikációja a szétválasztás legvilágosabb közzétett példája, mert a csomagot párként definiálja, a többit pedig a saját tárgyalásába helyezi. Ha ez a forma ismerős, az IPsec-javaslat és az egyetlen rögzített WireGuard-együttes ugyanazon ötlet változataként olvasható.

Olvassa el a tárgyalt eredményt, aztán álljon meg

A beállított javaslat nem bizonyíték arra, mit választott két fél. Az élő munkamenet hordozza a választ, és minden elterjedt megvalósítás jelentheti csomagrögzítés nélkül.

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

A kimenetben a kiválasztott algoritmusokat olvassa, ne a felkínált listát. Ha a válasz gyengébb annál, mint amit a szabályzat szánt, a javítás az egyik fél javaslat-konfigurációjában van, és az eltérés a modern megvalósításokban általában sikertelen tárgyalásként jelenik meg, nem csendes lefokozásként.

Aztán emlékezzen arra, mire nem terjed ki a csomag. Az útvonalak, az alkalmazásengedélyek, a naplózás és a megőrzés külön döntések saját felülvizsgálattal, és egy kompatibilis kriptográfiai elrendezés semmit sem mond róluk. A rejtjelezésről szóló vita megéri, de szűkebb kérdésre válaszol, mint amit a legtöbb ember valójában feltesz.

Tartsa pontosnak a szókincset, és az érv rövidebb lesz. A csomag szerepek együttese egy rétegen, a rejtjelező egy összetevő, és a tárgyalt eredmény az egyetlen, ami leírja a kapcsolatot, amely valóban van. Minden más az összehasonlításban díszítés.