Zašto AES-256 ne opisuje VPN paket za šifriranje
Paket ispunjava četiri uloge: skupno šifriranje, cjelovitost, uspostavljanje ključeva i provjera identiteta druge strane. Naziv šifre pokriva jednu od njih, na jednom sloju.
Pitajte koje šifriranje koristi VPN i odgovor obično dolazi kao jedna riječ: AES-256, ili ChaCha20, ili možda WireGuard. Taj odgovor imenuje jednu komponentu jednog sloja, dok je ono što zaista štiti vezu skup algoritama koji ispunjavaju četiri različite uloge. Miješanje komponente s rasporedom najčešća je greška u tim razgovorima i stvara poređenja koja se ne mogu razriješiti.
Četiri posla unutar jedne veze
Skupno šifriranje pretvara otvoreni tekst u šifrat za kanal podataka, a njegov ključ se izvodi, a ne prenosi. Zaštita cjelovitosti otkriva izmjenu, što je odvojen posao čak i kada jedna konstrukcija radi oboje. Uspostavljanje ključeva stvara zajednički materijal prometa, a provjera identiteta druge strane odlučuje ko 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 su autentificirane šifrirne konstrukcije, pa povjerljivost i cjelovitost dolaze zajedno; AES-CBC nije i treba mu 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 stoje i na različitim slojevima, zato 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 njegovog načina rada i sloja može biti gore od necitiranja ničega.
Zašto naziv šifre ne kaže gotovo ništa
Uzmite frazu AES-256 ozbiljno na trenutak: ona označava blokovnu šifru i veličinu ključa. Ne kaže ništa o načinu rada, 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 je to razdvajanje unio u standard, što je korisna ispravka za svakoga ko je učio stariji rječnik. Njegovi paketi šifri imenuju samo AEAD i hash, dok se grupe za razmjenu ključeva i algoritmi potpisa pregovaraju kao zasebni parametri. Zato se naziv paketa TLS 1.3 ne može porediti s nazivom paketa TLS 1.2 pod jednakim uvjetima, iako se oba pojavljuju u istom polju konfiguracijske datoteke. Revizor koji dva niza poredi izravno izvodi zaključak koji protokol ne podržava. Pročitajte i pregovaranu grupu i parametre potpisa, inače je poređenje nepotpuno.
WireGuard bira suprotan put i uklanja pregovaranje gotovo potpuno: protokol propisuje fiksni skup algoritama, pa dvije implementacije ili rade zajedno ili ne. To je legitiman dizajnerski izbor i znači i da pitanje koji paket WireGuard pregovara nema odgovor vrijedan poređenja. Ako ga revidirate, pročitajte specifikaciju jednom i 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, i to dvoje se može legitimno razlikovati. Čitanje prvog i pretpostavka da opisuje drugo čest je izvor zabune tijekom revizije, jer konfiguracijska datoteka spominje oba, a zanimljiv je drugi.
| 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žanog presjeka, a ne uključivanjem svakog starog algoritma na obje strane.
Specifikacija TLS 1.3 najjasniji je objavljeni primjer tog 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 varijante iste ideje.
Pročitajte pregovarani rezultat, pa stanite
Konfigurirani prijedlog nije dokaz šta su dva partnera odabrala. Živa sesija nosi odgovor i svaka glavna implementacija može ga prijaviti bez hvatanja paketa.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show
U izlazu čitajte odabrane algoritme, a ne ponuđeni popis. Ako je odgovor slabiji od predviđenog politikom, ispravak pripada konfiguraciji prijedloga na jednoj strani, a nesklad se u modernim implementacijama obično pokazuje kao neuspjelo pregovaranje, a ne kao tiho sniženje.
Zatim zapamtite šta paket ne pokriva. Rute, dozvole aplikacija, evidentiranje i čuvanje odvojene 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 komponenta, a pregovarani rezultat jedino je što opisuje vezu koju zaista imate. Sve ostalo u poređenju je ukras.