Kāpēc AES-256 neapraksta VPN šifrēšanas komplektu
Komplekts pilda četras lomas: masveida šifrēšana, integritāte, atslēgu izveide un partnera autentifikācija. Šifra nosaukums aptver tikai vienu no tām, vienā slānī.
Jautājiet, kādu šifrēšanu izmanto VPN, un atbilde parasti nāk vienā vārdā: AES-256, vai ChaCha20, vai varbūt WireGuard. Šī atbilde nosauc vienu viena slāņa komponentu, bet to, kas patiešām aizsargā savienojumu, ir algoritmu kopums, kas pilda četras dažādas lomas. Komponenta sajaukšana ar izkārtojumu ir visbiežākā kļūda šajās sarunās, un tā rada salīdzinājumus, kurus nevar atrisināt.
Četri darbi vienā savienojumā
Masveida šifrēšana pārvērš atklātu tekstu šifrētā tekstā datu kanālam, un tās atslēga tiek atvasināta, nevis pārsūtīta. Integritātes aizsardzība atklāj izmaiņas, un tas ir atsevišķs darbs, pat ja viena konstrukcija dara abus. Atslēgu izveide rada kopīgo trafika materiālu, un partnera autentifikācija izlemj, kas ir otrā galā. Ja trūkst kaut viena, savienojums nav drošs, lai cik spēcīga būtu atlikusī daļa.
Daži projekti apvieno divas lomas vienā. AES-GCM un ChaCha20-Poly1305 ir autentificētas šifrēšanas konstrukcijas, tāpēc konfidencialitāte un integritāte nāk kopā; AES-CBC nav, tam vajadzīgs atsevišķs ziņojuma autentifikācijas kods ar savu atslēgu. Tāpēc priekšlikuma lasīšana kā neatkarīgu skaitļu maisa nepareizi nolasa tos, kas projektēti kā pāri.
Lomas atrodas arī dažādos slāņos, tāpēc viens un tas pats vārds divos produktos var nozīmēt dažādas lietas. Bloka šifrs ESP iekšienē un bloka šifrs TLS iekšienē ir viens un tas pats primitīvs dažādās sarunās ar dažādām prasībām. Tāpēc primitīva citēšana bez tā režīma un slāņa var būt sliktāka par neko necitēšanu.
Kāpēc šifra nosaukums gandrīz neko nepasaka
Uztveriet frāzi AES-256 nopietni uz brīdi: tā norāda bloka šifru un atslēgas lielumu. Tā neko nepasaka par darbības režīmu, vai integritāte tiek nodrošināta, kā tika izveidotas atslēgas vai kā tika autentificēts partneris. Divi produkti var abi reklamēt AES-256 un atšķirties visā citā, tostarp viens ar neautentificētu režīmu un otrs ar AEAD režīmu un mūsdienīgu atslēgu apmaiņu.
TLS 1.3 iekļāva šo atdalīšanu standartā, kas ir noderīgs labojums ikvienam, kurš mācījies vecāko vārdu krājumu. Tā šifru komplekti nosauc tikai AEAD un jaucējfunkciju, bet atslēgu apmaiņas grupas un paraksta algoritmi tiek apspriesti kā atsevišķi parametri. Tāpēc TLS 1.3 komplekta nosaukums nav salīdzināms ar TLS 1.2 komplekta nosaukumu vienlīdzīgos apstākļos, lai gan abi parādās vienā un tajā pašā konfigurācijas faila laukā. Auditors, kurš salīdzina abas virknes tieši, izdara secinājumu, ko protokols neatbalsta. Izlasiet arī apspriesto grupu un paraksta parametrus, citādi salīdzinājums ir nepilnīgs.
WireGuard izvēlas pretējo ceļu un gandrīz pilnībā noņem sarunas: protokols nosaka fiksētu algoritmu kopumu, tāpēc divas implementācijas vai nu darbojas kopā, vai ne. Tā ir likumīga dizaina izvēle, un tas arī nozīmē, ka jautājumam, kuru komplektu WireGuard apspriež, nav salīdzināšanas vērta atbilde. Ja jūs to auditējat, izlasiet specifikāciju vienreiz un pēc tam auditējiet atslēgu pārvaldību ap to, nevis sarunas.
Slānis nosaka vārdu krājumu
IPsec izvietojums apspriež divreiz: IKE priekšlikums vadības kanālam un ESP transformācija datiem, un abi var likumīgi atšķirties. Pirmā lasīšana un pieņēmums, ka tas apraksta otro, ir biežs apjukuma avots audita laikā, jo konfigurācijas fails min abus, un interesantais ir otrais.
| 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 |
Nosaukums, kas pieejams vienā bibliotēkā, netiek automātiski ieviests citam datu ceļam. Tāpēc apgalvojums, ka mūsu produkts atbalsta AES-256, ir vājāks, nekā izklausās, un tāpēc savietojamības problēma parasti tiek risināta, atrodot uzturēto krustojumu, nevis iespējojot katru veco algoritmu abās pusēs.
TLS 1.3 specifikācija ir skaidrākais publicētais šīs atdalīšanas piemērs, jo tā definē komplektu kā pāri un pārējo pārvieto uz savām sarunām. Kad šī forma ir pazīstama, IPsec priekšlikums un vienīgais fiksētais WireGuard kopums tiek lasīti kā tās pašas idejas varianti.
Izlasiet apspriesto rezultātu un tad apstājieties
Konfigurēts priekšlikums nav pierādījums tam, ko izvēlējušies divi partneri. Dzīvā sesija nes atbildi, un jebkura izplatīta implementācija var to ziņot, nefiksējot paketes.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showIzvadā lasiet izvēlētos algoritmus, nevis piedāvāto sarakstu. Ja atbilde ir vājāka, nekā politika bija paredzējusi, labojums pieder priekšlikuma konfigurācijai vienā pusē, un neatbilstība mūsdienu implementācijās parasti izpaužas kā neveiksmīgas sarunas, nevis kā klusa pazemināšana.
Pēc tam atcerieties, ko komplekts neaptver. Maršruti, lietotņu atļaujas, žurnālēšana un uzglabāšana ir atsevišķi lēmumi ar savu pārskatu, un saderīgs kriptogrāfiskais izkārtojums par tiem neko nepasaka. Šifra diskusija ir tā vērta, bet tā atbild uz šaurāku jautājumu nekā to, ko vairums cilvēku patiešām uzdod.
Turiet vārdu krājumu precīzu, un arguments kļūs īsāks. Komplekts ir lomu kopums slānī, šifrs ir viens komponents, un apspriestais rezultāts ir vienīgais, kas apraksta savienojumu, kas jums patiešām ir. Viss pārējais salīdzinājumā ir rotājums.