Zašto AES-256 ne opisuje VPN šifrirni paket
Paket ispunjava četiri uloge: skupno šifriranje, cjelovitost, uspostava ključeva i provjera identiteta druge strane. Naziv šifre pokriva samo jednu od njih, na jednom sloju.
Pitate li koje šifriranje rabi VPN, odgovor obično stiže kao jedna riječ: AES-256, ili ChaCha20, ili možda WireGuard. Taj odgovor imenuje jednu sastavnicu jednoga sloja, dok je ono što doista štiti vezu skup algoritama koji ispunjavaju četiri različite uloge. Zamjena sastavnice s rasporedom najčešća je pogreška u takvim razgovorima i stvara usporedbe koje se ne mogu razriješiti.
Četiri posla unutar jedne veze
Skupno šifriranje pretvara otvoreni tekst u šifrat za kanal podataka, a njegov se ključ izvodi umjesto prenosi. Zaštita cjelovitosti otkriva promjenu, što je zaseban posao čak i kad jedna konstrukcija obavlja oboje. Uspostava ključeva stvara zajednički prometni materijal, a provjera identiteta druge strane odlučuje tko je na drugom kraju. Nedostaje li ijedna od njih, veza nije sigurna, koliko god preostali dio bio jak.
Neki nacrti spajaju dvije uloge u jednu. AES-GCM i ChaCha20-Poly1305 autentificirane su šifrirne konstrukcije, pa povjerljivost i cjelovitost dolaze zajedno; AES-CBC nije, njemu treba zaseban kôd za provjeru poruke s vlastitim ključem. Zato čitanje prijedloga kao vreće neovisnih brojeva pogrešno čita one koji su zamišljeni kao parovi.
Uloge leže i na različitim slojevima, pa ista riječ u dva proizvoda može značiti različito. Blokovna šifra u ESP-u i blokovna šifra u TLS-u isti su primitiv u različitim pregovorima s različitim zahtjevima. Zato citiranje primitiva bez njegova načina rada i sloja može biti gore od necitiranja ničega.
Zašto naziv šifre gotovo ništa ne kaže
Uzmite frazu AES-256 na trenutak ozbiljno: ona označava blokovnu šifru i veličinu ključa. Ne kaže ništa o načinu rada, o tome je li cjelovitost osigurana, kako su ključevi uspostavljeni ili kako je druga strana provjerena. Dva proizvoda mogu oba reklamirati AES-256 i razlikovati se u svemu ostalom, uključujući jedan s neautentificiranim načinom i drugi s AEAD načinom i modernom razmjenom ključeva.
TLS 1.3 unio je to razdvajanje u standard, što je korisna ispravka za svakoga tko je učio stariji rječnik. Njegovi šifrirni paketi imenuju samo AEAD i hash, dok se skupine za razmjenu ključeva i algoritmi potpisa pregovaraju kao zasebni parametri. Zato se naziv paketa TLS 1.3 ne može usporediti s nazivom paketa TLS 1.2 pod istim uvjetima, iako se oba pojavljuju u istom polju konfiguracijske datoteke. Revizor koji dva niza usporedi izravno donosi zaključak koji protokol ne podupire. Pročitajte i pregovaranu skupinu i parametre potpisa, inače je usporedba nepotpuna.
WireGuard bira suprotan put i uklanja pregovaranje gotovo posve: protokol propisuje fiksni skup algoritama, pa dvije implementacije ili surađuju ili ne. To je legitiman dizajnerski odabir i znači i to da pitanje koji paket WireGuard pregovara nema odgovor vrijedan usporedbe. Ako ga revidirate, pročitajte specifikaciju jednom pa zatim revidirajte upravljanje ključevima oko nje, umjesto pregovaranja.
Sloj određuje rječnik
Uvođenje IPsec-a pregovara dvaput: IKE prijedlog za kontrolni kanal i ESP transformaciju za podatke, a to se dvoje može legitimno razlikovati. Čitanje prvoga i pretpostavka da opisuje drugo čest je izvor zbrke tijekom revizije, jer konfiguracijska datoteka spominje oboje, a zanimljivo je drugo.
| 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 |
Naziv dostupan u jednoj biblioteci nije automatski implementiran za drugi put podataka. Zato je tvrdnja da naš proizvod podržava AES-256 slabija nego što zvuči, i zato se problem interoperabilnosti obično rješava pronalaženjem održanoga presjeka, a ne uključivanjem svakog starog algoritma na obje strane.
Specifikacija TLS 1.3 najjasniji je objavljeni primjer toga razdvajanja jer paket definira kao par i ostatak premješta u vlastito pregovaranje. Kad je taj oblik poznat, IPsec prijedlog i jedini fiksni WireGuard skup čitaju se kao inačice iste ideje.
Pročitajte pregovarani rezultat, pa stanite
Konfigurirani prijedlog nije dokaz što su dva partnera odabrala. Živa sesija nosi odgovor, a svaka glavna implementacija može ga prijaviti bez hvatanja paketa.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showU izlazu čitajte odabrane algoritme, a ne ponuđeni popis. Ako je odgovor slabiji od predviđenoga politikom, ispravak pripada konfiguraciji prijedloga na jednoj strani, a nesklad se u modernim implementacijama obično pokaže kao neuspjelo pregovaranje, a ne kao tiho sniženje.
Zatim se sjetite što paket ne pokriva. Rute, dozvole aplikacija, evidentiranje i čuvanje zasebne su odluke s vlastitim pregledom, a kompatibilan kriptografski raspored ne kaže ništa o njima. Razgovor o šifri vrijedi, ali odgovara na uže pitanje od onoga koje većina ljudi zapravo postavlja.
Držite rječnik preciznim i argument postaje kraći. Paket je skup uloga na sloju, šifra je jedna sastavnica, a pregovarani rezultat jedino je što opisuje vezu koju doista imate. Sve ostalo u usporedbi je ukras.