Kial AES-256 ne priskribas VPN-ĉifran aron
Aro plenumas kvar rolojn: amasa ĉifrado, integreco, ŝlosila starigo kaj aŭtentigo de la kontraŭparto. Ĉifra nomo kovras unu el ili, sur unu tavolo.
Demandu, kiun ĉifradon uzas VPN, kaj la respondo kutime venas kiel unu vorto: AES-256, aŭ ChaCha20, aŭ eble WireGuard. Tiu respondo nomas unu komponanton de unu tavolo, dum tio, kio vere protektas la konekton, estas aro da algoritmoj, kiuj plenumas kvar malsamajn rolojn. Konfuzi la komponanton kun la aranĝo estas la plej ofta eraro en tiuj konversacioj, kaj ĝi produktas komparojn, kiujn oni ne povas solvi.
Kvar taskoj en unu konekto
Amasa ĉifrado ŝanĝas klartekston en ĉifrotekston por la datumkanalo, kaj ĝia ŝlosilo estas derivata anstataŭ transdonata. Integreca protekto detektas ŝanĝon, kio estas aparta tasko eĉ kiam unu konstruaĵo faras ambaŭ. Ŝlosila starigo produktas la komunan trafikan materialon, kaj aŭtentigo de la kontraŭparto decidas, kiu estas ĉe la alia fino. Se mankas unu el ili, la konekto ne estas sekura, kiom ajn forta estas la restanta peco.
Kelkaj dezajnoj kunigas du rolojn en unu. AES-GCM kaj ChaCha20-Poly1305 estas aŭtentikigitaj ĉifraj konstruaĵoj, do konfideco kaj integreco venas kune; AES-CBC ne, kaj bezonas apartan mesaĝan aŭtentigan kodon kun propra ŝlosilo. Do legi proponon kiel sakon da sendependaj nombroj malĝuste legas tiujn, kiuj estis dezajnitaj kiel paroj.
La roloj ankaŭ kuŝas sur malsamaj tavoloj, kaj tial la sama vorto povas signifi malsamajn aferojn en du produktoj. Bloka ĉifro en ESP kaj bloka ĉifro en TLS estas la sama primitivo en malsamaj intertraktadoj kun malsamaj postuloj. Tial citi primitivon sen ĝia reĝimo kaj tavolo povas esti pli malbone ol citi nenion.
Kial ĉifra nomo preskaŭ diras nenion
Prenu la frazon AES-256 serioze por momento: ĝi identigas blokan ĉifron kaj ŝlosilan grandecon. Ĝi diras nenion pri la funkcia reĝimo, ĉu integreco estas provizita, kiel la ŝlosiloj estis starigitaj aŭ kiel la kontraŭparto estis aŭtentigita. Du produktoj povas ambaŭ reklami AES-256 kaj malsami en ĉio alia, inkluzive unu kun neaŭtentigita reĝimo kaj alia kun AEAD-reĝimo kaj moderna ŝlosilinterŝanĝo.
TLS 1.3 portis tiun apartigon en la normon, kio estas utila korekto por ĉiu, kiu lernis la pli malnovan vortaron. Ĝiaj ĉifraj aroj nomas nur la AEAD kaj la haketon, dum ŝlosilinterŝanĝaj grupoj kaj subskribaj algoritmoj estas intertraktataj kiel apartaj parametroj. Do la nomo de TLS 1.3-aro ne estas komparebla kun la nomo de TLS 1.2-aro sur egala bazo, kvankam ambaŭ aperas en la sama kampo de agorda dosiero. Reviziisto, kiu komparas la du ĉenojn rekte, tiras konkludon, kiun la protokolo ne subtenas. Legu ankaŭ la intertraktitan grupon kaj la subskribajn parametrojn, alie la komparo estas nekompleta.
WireGuard elektas la kontraŭan vojon kaj forigas intertraktadon preskaŭ tute: la protokolo fiksas difinitan algoritman aron, do du efektivigoj aŭ kunlaboras aŭ ne. Tio estas laŭleĝa dezajna elekto, kaj ĝi ankaŭ signifas, ke la demando, kiun aron WireGuard intertraktas, ne havas respondon indan je komparo. Se vi revizias ĝin, legu la specifon unufoje kaj poste reviziu la ŝlosilan traktadon ĉirkaŭ ĝi anstataŭ la intertraktadon.
La tavolo decidas la vortaron
IPsec-agordo intertraktas dufoje: IKE-propono por la regkanalo kaj ESP-transformo por la datumoj, kaj la du povas laŭleĝe malsami. Legi la unuan kaj supozi, ke ĝi priskribas la duan, estas ofta fonto de konfuzo dum revizio, ĉar la agorda dosiero mencias ambaŭ kaj la interesa estas la dua.
| 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 |
Nomo havebla en unu biblioteko ne estas aŭtomate efektivigita por alia datuma vojo. Tial la aserto, ke nia produkto subtenas AES-256, estas pli malforta ol ĝi sonas, kaj tial interoperacia problemo kutime solviĝas per trovado de la konservata komunaĵo anstataŭ per ŝaltado de ĉiu malnova algoritmo ambaŭflanke.
La specifo de TLS 1.3 estas la plej klara publikigita ekzemplo de la apartigo, ĉar ĝi difinas la aron kiel paron kaj movas la reston al sia propra intertraktado. Iam tiu formo estas konata, la IPsec-propono kaj la unu fiksa WireGuard-aro legeblas kiel variantoj de la sama ideo.
Legu la intertraktitan rezulton, poste haltu
Agordita propono ne estas pruvo pri tio, kion du kontraŭpartoj elektis. La viva seanco portas la respondon, kaj ĉiu ĉefa efektivigo povas raporti ĝin sen kapti pakaĵojn.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showEn la eligo legu la elektitajn algoritmojn anstataŭ la ofertitan liston. Se la respondo estas pli malforta ol la politiko intencis, la korekto apartenas al la propona agordo unuflanke, kaj malkongruo montriĝas en modernaj efektivigoj kutime kiel malsukcesa intertraktado anstataŭ kiel silenta malaltigo.
Poste memoru, kion la aro ne kovras. Itineroj, aplikaĵpermesoj, protokolado kaj konservado estas apartaj decidoj kun propra revizio, kaj kongrua kriptografia aranĝo diras nenion pri ili. La ĉifra diskuto indas, sed ĝi respondas pli mallarĝan demandon ol tiu, kiun plej multaj homoj fakte faras.
Tenu la vortaron preciza kaj la argumento mallongiĝas. Aro estas aro da roloj sur tavolo, ĉifro estas unu komponanto, kaj la intertraktita rezulto estas la sola afero, kiu priskribas la konekton, kiun vi efektive havas. Ĉio alia en la komparo estas ornamo.