Hvorfor AES-256 ikke beskriver en VPN-krypteringspakke
En pakke fyller fire roller: bulkkryptering, integritet, nøkkeloppsett og autentisering av motparten. Et chiffenavn dekker bare én av dem, på ett lag.
Spør hvilken kryptering en VPN bruker, og svaret kommer vanligvis som ett ord: AES-256, eller ChaCha20, eller kanskje WireGuard. Det svaret navngir én komponent på ett lag, mens det som faktisk beskytter forbindelsen er et sett algoritmer som fyller fire ulike roller. Å forveksle komponenten med oppsettet er den vanligste feilen i disse samtalene, og den produserer sammenligninger som ikke kan avgjøres.
Fire oppgaver i én forbindelse
Bulkkryptering gjør klartekst om til chiffentekst for datakanalen, og nøkkelen utledes i stedet for å overføres. Integritetsbeskyttelse oppdager endring, noe som er en separat oppgave selv når én konstruksjon gjør begge. Nøkkeloppsett lager felles trafikkmateriale, og autentisering av motparten avgjør hvem som er i andre enden. Mangler én av dem, er forbindelsen ikke sikker, uansett hvor sterk resten er.
Noen design slår sammen to roller. AES-GCM og ChaCha20-Poly1305 er autentiserte krypteringskonstruksjoner, så konfidensialitet og integritet kommer sammen; AES-CBC gjør ikke det og trenger en egen meldingsautentiseringskode med sin egen nøkkel. Derfor leser man feil når man leser et forslag som en pose uavhengige tall, for de som er designet som par.
Rollene ligger også på ulike lag, og derfor kan samme ord bety flere ting i to produkter. En blokkchiffer i ESP og en blokkchiffer i TLS er samme primitiv i ulike forhandlinger med ulike krav. Derfor kan det å sitere en primitiv uten modus og lag være verre enn å ikke sitere noe.
Hvorfor et chiffenavn nesten ikke sier noe
Ta uttrykket AES-256 alvorlig et øyeblikk: det angir en blokkchiffer og en nøkkelstørrelse. Det sier ingenting om driftsmodus, om integritet leveres, hvordan nøkler ble etablert eller hvordan motparten ble autentisert. To produkter kan begge annonsere AES-256 og være ulike på alle andre punkter, inkludert ett med en ikke-autentisert modus og ett med AEAD-modus og moderne nøkkelutveksling.
TLS 1.3 løftet denne adskillelsen inn i standarden, noe som er en nyttig korreksjon for alle som lærte det eldre ordforrådet. Chiffersuitene navngir bare AEAD og hashen, mens nøkkelutvekslingsgrupper og signaturalgoritmer forhandles som egne parametere. Derfor kan ikke et TLS 1.3-suitenavn sammenlignes med et TLS 1.2-suitenavn på like vilkår, selv om begge vises i samme felt i en konfigurasjonsfil. En revisor som sammenligner de to strengene direkte, trekker en konklusjon protokollen ikke støtter. Les også den forhandlede gruppen og signaturparameterne, ellers er sammenligningen ufullstendig.
WireGuard velger motsatt vei og fjerner forhandlingen nesten helt: protokollen fastsetter et fast algoritmesett, så to implementasjoner enten samhandler eller ikke. Det er et legitimt designvalg, og det betyr også at spørsmålet om hvilken suite WireGuard forhandler ikke har et svar som er verdt å sammenligne. Hvis du reviderer det, les spesifikasjonen én gang og revider deretter nøkkelhåndteringen rundt den i stedet for forhandlingen.
Laget bestemmer ordforrådet
En IPsec-utrulling forhandler to ganger: et IKE-forslag for kontrollkanalen og en ESP-transformasjon for dataene, og de to kan lovlig avvike. Å lese det første og anta at det beskriver det andre er en vanlig kilde til forvirring under en revisjon, fordi konfigurasjonsfilen nevner 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 |
Et navn som er tilgjengelig i ett bibliotek, blir ikke automatisk implementert for en annen datasti. Derfor er påstanden om at produktet vårt støtter AES-256 svakere enn den høres, og derfor løses et interoperabilitetsproblem vanligvis ved å finne det vedlikeholdte snittet i stedet for å aktivere hver gammel algoritme på begge sider.
Spesifikasjonen for TLS 1.3 er det klareste publiserte eksempelet på adskillelsen, fordi den definerer suiten som et par og flytter resten til deres egen forhandling. Når denne formen er kjent, leses IPsec-forslaget og det ene faste WireGuard-settet som varianter av samme idé.
Les det forhandlede resultatet, og stopp så
Et konfigurert forslag er ikke bevis for hva to parter valgte. Den levende sesjonen bærer svaret, og enhver vanlig implementasjon kan rapportere det uten å fange pakker.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showI utdataene leser du de valgte algoritmene i stedet for den tilbudte listen. Hvis svaret er svakere enn politikken tilsiktet, hører rettelsen hjemme i forslagets konfigurasjon på den ene eller andre siden, og et avvik viser seg i moderne implementasjoner vanligvis som en mislykket forhandling snarere enn en stille nedgradering.
Husk så hva pakken ikke dekker. Ruter, applikasjonstillatelser, logging og oppbevaring er egne beslutninger med sin egen gjennomgang, og et kompatibelt kryptografisk oppsett sier ingenting om dem. Chifferdiskusjonen er verdt å ha, men den besvarer et snevrere spørsmål enn det de fleste faktisk stiller.
Hold ordforrådet presist, og argumentet blir kortere. En pakke er et sett roller på et lag, en chiffer er én komponent, og det forhandlede resultatet er det eneste som beskriver forbindelsen du faktisk har. Alt annet i sammenligningen er dekorasjon.