Zasto AES-256 ne opisuje VPN sifrovni paket
Paket ispunjava cetiri uloge: skupno sifrovanje, integritet, uspostava kljuceva i provera identiteta druge strane. Naziv sifre 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 komponentu jednoga sloja, dok je ono što doista štiti spoj 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 spoja
Skupno šifriranje pretvara otvoreni tekst u šifrat za kanal podataka, a njegov se ključ izvodi umjesto prenosi. Zaštita integriteti 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, spoj 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 integritet 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 integritet 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 dogovaraju kao zasebni parametri. Zato se naziv paketa TLS 1.3 ne može usporediti s nazivom paketa TLS 1.2 pod istim uslovima, 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 dogovaranu skupinu i parametre potpisa, inače je usporedba nepotpuna.
WireGuard bira suprotan put i uklanja dogovaranje 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 dogovara nema odgovor vrijedan usporedbe. Ako ga revidirate, pročitajte specifikaciju jednom pa zatim revidirajte upravljanje ključevima oko nje, umjesto dogovaranja.
Sloj određuje rječnik
Uvođenje IPsec-a dogovara 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 zabune tokom 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žanog 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 dogovaranje. Kad je taj oblik poznat, IPsec prijedlog i jedini fiksni WireGuard skup čitaju se kao inačice iste ideje.
Pročitajte dogovoreni 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đenog politikom, ispravak pripada konfiguraciji prijedloga na jednoj strani, a nesklad se u modernim implementacijama obično pokaže kao neuspjelo dogovaranje, 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 komponenta, a dogovoreni rezultat jedino je što opisuje spoj koju doista imate. Sve ostalo u usporedbi je ukras.