Kvifor AES-256 ikkje skildrar ein VPN-krypteringspakke
Ein pakke fyller fire rollar: bulkkryptering, integritet, nøkkeloppsett og autentisering av motparten. Eit chiffennamn dekkjer berre éin av dei, på eitt lag.
Spør kva kryptering ein VPN nyttar, og svaret kjem vanlegvis som eitt ord: AES-256, eller ChaCha20, eller kanskje WireGuard. Det svaret nemner éin komponent på eitt lag, medan det som faktisk vernar sambandet er eit sett algoritmar som fyller fire ulike rollar. Å blande komponenten med oppsettet er den vanlegaste feilen i desse samtalane, og han gjev samanlikningar som ikkje kan avgjerast.
Fire oppgåver i eitt samband
Bulkkryptering gjer klartekst om til chiffentekst for datakanalen, og nøkkelen vert utleidd i staden for overført. Integritetsvern oppdagar endring, noko som er ei separat oppgåve sjølv når éin konstruksjon gjer begge. Nøkkeloppsett lagar felles trafikkmateriale, og autentisering av motparten avgjer kven som er i andre enden. Manglar éin av dei, er sambandet ikkje trygt, uansett kor sterkt resten er.
Nokre design slår saman to rollar. AES-GCM og ChaCha20-Poly1305 er autentiserte krypteringskonstruksjonar, så konfidensialitet og integritet kjem saman; AES-CBC gjer ikkje det og treng ein eigen meldingsautentiseringskode med sin eigen nøkkel. Derfor les ein feil når ein les eit framlegg som ein pose uavhengige tal, for dei som er designa som par.
Rollar ligg òg på ulike lag, og derfor kan same ordet tyde ulike ting i to produkt. Ein blokkciffer i ESP og ein blokkciffer i TLS er same primitive i ulike forhandlingar med ulike krav. Derfor kan det å sitere ein primitiv utan modus og lag vere verre enn å ikkje sitere noko.
Kvifor eit chiffennamn nesten ikkje seier noko
Ta uttrykket AES-256 alvorleg eit augeblikk: det angir ein blokkciffer og ein nøkkelstorleik. Det seier ingenting om driftsmodus, om integritet vert levert, korleis nøklar vart etablerte eller korleis motparten vart autentisert. To produkt kan begge annonsere AES-256 og vere ulike på alle andre punkt, mellom anna eitt med ein ikkje-autentisert modus og eitt med AEAD-modus og moderne nøkkelutveksling.
TLS 1.3 lyfta denne åtskiljinga inn i standarden, noko som er ei nyttig retting for alle som lærte det eldre ordforrådet. Chiffersuitane nemner berre AEAD og hashen, medan nøkkelutvekslingsgrupper og signaturalgoritmar vert forhandla som eigne parametrar. Derfor kan ikkje eit TLS 1.3-suitenamn samanliknast med eit TLS 1.2-suitenamn på like vilkår, sjølv om begge viser seg i same felt i ei konfigurasjonsfil. Ein revisor som samanliknar dei to strengane direkte, dreg ei slutning protokollen ikkje støttar. Les òg den forhandla gruppa og signaturparametrane, elles er samanlikninga ufullstendig.
WireGuard vel motsett veg og fjernar forhandlinga nesten heilt: protokollen fastset eit fast algoritmesett, så to implementasjonar samhandlar eller ikkje. Det er eit legitimt designval, og det tyder òg at spørsmålet om kva suite WireGuard forhandlar ikkje har eit svar som er verdt å samanlikne. Viss du reviderer det, les spesifikasjonen éin gong og revider deretter nøkkelhandteringa rundt han i staden for forhandlinga.
Laget avgjer ordforrådet
Ei IPsec-utrulling forhandlar to gonger: eit IKE-framlegg for kontrollkanalen og ein ESP-transformasjon for dataa, og dei to kan lovleg avvike. Å lese det første og anta at det skildrar det andre er ei vanleg kjelde til forvirring under ein revisjon, fordi konfigurasjonsfila nemner begge, og den interessante er den andre.
| 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 |
Eit namn som er tilgjengeleg i eitt bibliotek, vert ikkje automatisk implementert for ein annan datasti. Derfor er påstanden om at produktet vårt støttar AES-256 svakare enn han høyrest, og derfor vert eit interoperabilitetsproblem vanlegvis løyst ved å finne det vedlikehaldne snittet i staden for å slå på kvar gamal algoritme på begge sider.
Spesifikasjonen for TLS 1.3 er det klåraste publiserte dømet på åtskiljinga, fordi han definerer suiten som eit par og flyttar resten til si eiga forhandling. Når denne forma er kjend, vert IPsec-framlegget og det eine faste WireGuard-settet lesne som variantar av same idé.
Les det forhandla resultatet, og stopp så
Eit konfigurert framlegg er ikkje prov for kva to partar valde. Den levande sesjonen ber svaret, og kvar vanleg implementasjon kan rapportere det utan å fange pakkar.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showI utdataa les du dei valde algoritmane i staden for den tilbodne lista. Viss svaret er svakare enn politikken tilsikta, høyrer rettinga heime i framleggskonfigurasjonen på den eine eller andre sida, og eit avvik viser seg i moderne implementasjonar vanlegvis som ei mislukka forhandling snarare enn ei stille nedgradering.
Hugs så kva pakken ikkje dekkjer. Ruter, applikasjonstilgangar, logging og oppbevaring er eigne avgjerder med si eiga gjennomgang, og eit kompatibelt kryptografisk oppsett seier ingenting om dei. Chifferdiskusjonen er verdt å ha, men han svarar på eit snevrare spørsmål enn det dei fleste faktisk stiller.
Hald ordforrådet presist, og argumentet vert kortare. Ein pakke er eit sett rollar på eitt lag, ein chiffer er éin komponent, og det forhandla resultatet er det einaste som skildrar sambandet du faktisk har. Alt anna i samanlikninga er dekorasjon.