Zakaj AES-256 ne opisuje nabora šifriranja VPN
Nabor opravlja štiri vloge: množično šifriranje, celovitost, vzpostavitev ključev in preverjanje partnerja. Ime šifre pokriva le eno od njih, na enem sloju.
Vprašajte, katero šifriranje uporablja VPN, in odgovor običajno pride kot ena beseda: AES-256, ali ChaCha20, ali morda WireGuard. Ta odgovor poimenuje eno komponento enega sloja, medtem ko je tisto, kar povezavo res varuje, nabor algoritmov, ki opravljajo štiri različne vloge. Zamenjava komponente s postavitvijo je najpogostejša napaka v teh pogovorih in ustvarja primerjave, ki jih ni mogoče razrešiti.
Štiri opravila v eni povezavi
Množično šifriranje spremeni jasno besedilo v šifrirano za podatkovni kanal, njegov ključ pa se izpelje, ne pošlje. Zaščita celovitosti zazna spremembo, kar je ločeno opravilo, tudi ko ena konstrukcija opravi oboje. Vzpostavitev ključev ustvari skupni prometni material, preverjanje partnerja pa odloči, kdo je na drugem koncu. Če manjka karkoli od tega, povezava ni varna, ne glede na to, kako močan je preostali del.
Nekatere zasnove združijo dve vlogi v eno. AES-GCM in ChaCha20-Poly1305 sta overjeni šifrirni konstrukciji, zato zaupnost in celovitost prideta skupaj; AES-CBC ni, potrebuje ločeno kodo za overjanje sporočila z lastnim ključem. Zato branje predloga kot vreče neodvisnih števil napačno bere tiste, ki so zasnovani kot pari.
Vloge ležijo tudi na različnih slojih, zato lahko ista beseda v dveh izdelkih pomeni različno. Bločna šifra v ESP in bločna šifra v TLS sta isti primitiv v različnih pogajanjih z različnimi zahtevami. Zato je navajanje primitiva brez njegovega načina in sloja lahko slabše od nenavajanja ničesar.
Zakaj ime šifre skoraj nič ne pove
Vzemite izraz AES-256 za trenutek resno: označuje bločno šifro in velikost ključa. Ne pove nič o načinu delovanja, o tem, ali je zagotovljena celovitost, kako so bili ključi vzpostavljeni ali kako je bil partner overjen. Dva izdelka lahko oba oglašujeta AES-256 in se razlikujeta v vsem drugem, vključno z enim z neoverjenim načinom in drugim z načinom AEAD in sodobno izmenjavo ključev.
TLS 1.3 je to ločevanje vnesel v standard, kar je koristen popravek za vsakogar, ki se je učil starejšega besedišča. Njegovi šifrirni nabori poimenujejo le AEAD in zgoščevalno funkcijo, medtem ko se skupine za izmenjavo ključev in algoritmi podpisa dogovarjajo kot ločeni parametri. Zato imena nabora TLS 1.3 ni mogoče primerjati z imenom nabora TLS 1.2 pod enakimi pogoji, čeprav se oba pojavita v istem polju konfiguracijske datoteke. Revizor, ki oba niza primerja neposredno, naredi sklep, ki ga protokol ne podpira. Preberite tudi dogovorjeno skupino in parametre podpisa, sicer je primerjava nepopolna.
WireGuard izbere nasprotno pot in pogajanja skoraj povsem odpravi: protokol predpisuje fiksni nabor algoritmov, zato dve izvedbi bodisi sodelujeta bodisi ne. To je legitimna oblikovalska izbira in pomeni tudi, da vprašanje, kateri nabor se pogaja pri WireGuard, nima odgovora, vrednega primerjave. Če ga revidirate, preberite specifikacijo enkrat in nato revidirajte upravljanje ključev okoli nje, namesto pogajanj.
Sloj določa besedišče
Uvedba IPsec se pogaja dvakrat: predlog IKE za krmilni kanal in pretvorbo ESP za podatke, in oba se lahko zakonito razlikujeta. Branje prvega in domneva, da opisuje drugega, je pogost vir zmede med revizijo, ker konfiguracijska datoteka omenja oba, zanimiv pa 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 |
Ime, ki je na voljo v eni knjižnici, ni samodejno izvedeno za drugo podatkovno pot. Zato je trditev, da naš izdelek podpira AES-256, šibkejša, kot se sliši, in zato se problem medobratovalnosti običajno reši z iskanjem vzdrževanega preseka, ne z omogočanjem vsakega starega algoritma na obeh straneh.
Specifikacija TLS 1.3 je najjasnejši objavljeni primer tega ločevanja, ker nabor definira kot par in preostanek prestavi v lastna pogajanja. Ko je ta oblika znana, se predlog IPsec in edini fiksni nabor WireGuard bereta kot različici iste zamisli.
Preberite dogovorjeni rezultat in se nato ustavite
Nastavljen predlog ni dokaz, kaj sta izbrala dva partnerja. Živa seja nosi odgovor in vsaka običajna izvedba ga lahko poroča brez zajemanja paketov.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showV izpisu berite izbrane algoritme, ne ponujenega seznama. Če je odgovor šibkejši, kot je nameravala politika, popravek spada v konfiguracijo predloga na eni od strani, in nesklad se v sodobnih izvedbah običajno pokaže kot neuspelo pogajanje, ne kot tiho znižanje.
Nato se spomnite, česa nabor ne pokriva. Poti, dovoljenja aplikacij, beleženje in hramba so ločene odločitve z lastnim pregledom, in združljiva kriptografska postavitev o njih ne pove ničesar. Razprava o šifri je vredna, a odgovarja na ožje vprašanje od tistega, ki ga večina ljudi dejansko postavi.
Ohranite besedišče natančno in argument se skrajša. Nabor je skupek vlog na sloju, šifra je ena komponenta, in dogovorjeni rezultat je edino, kar opisuje povezavo, ki jo res imate. Vse drugo v primerjavi je okras.