Hvorfor AES-256 ikke beskriver en VPN-krypteringspakke
En pakke udfylder fire roller: bulkkryptering, integritet, nøgleetablering og peer-godkendelse. Et chiffernavn dækker én af dem, på ét lag.
Spørg hvilken kryptering en VPN bruger, og svaret kommer normalt som ét ord: AES-256, eller ChaCha20, eller måske WireGuard. Det svar navngiver én komponent i ét lag, mens det, der faktisk beskytter forbindelsen, er et sæt algoritmer, der udfylder fire forskellige roller. At forveksle komponenten med arrangementet er den mest almindelige fejl i disse samtaler, og den producerer sammenligninger, der ikke kan afgøres.
Fire opgaver i én forbindelse
Bulkkryptering omdanner klartekst til chiffertekst til datakanalen, og dens nøgle udledes i stedet for at blive overført. Integritetsbeskyttelse opdager ændring, hvilket er en separat opgave, selv når én konstruktion udfører begge. Nøgleetablering frembringer det fælles trafikmateriale, og peer-godkendelse afgør, hvem der er i den anden ende. Mangler én af dem, er forbindelsen ikke sikker, uanset hvor stærk den resterende del er.
Nogle design slår to roller sammen. AES-GCM og ChaCha20-Poly1305 er autentificerede krypteringskonstruktioner, så fortrolighed og integritet kommer sammen; AES-CBC gør ikke, og kræver en separat meddelelsesgodkendelseskode med sin egen nøgle. At læse et forslag som en pose uafhængige tal læser derfor forkert dem, der blev designet som par.
Rollerne ligger også på forskellige lag, og derfor kan det samme ord betyde forskellige ting i to produkter. En blokciffer i ESP og en blokciffer i TLS er den samme primitiv i forskellige forhandlinger med forskellige krav. Derfor kan det være værre at citere en primitiv uden dens tilstand og lag end ikke at citere noget.
Hvorfor et chiffernavn næsten intet siger
Tag udtrykket AES-256 alvorligt et øjeblik: det angiver en blokciffer og en nøglestørrelse. Det siger intet om driftstilstanden, om integritet er tilvejebragt, hvordan nøgler blev etableret, eller hvordan peeren blev godkendt. To produkter kan begge reklamere med AES-256 og være forskellige på alle andre punkter, herunder ét med en ikke-autentificeret tilstand og ét med AEAD-tilstand og moderne nøgleudveksling.
TLS 1.3 løftede denne adskillelse ind i standarden, hvilket er en nyttig rettelse for alle, der lærte det ældre ordforråd. Dets chiffersuiter navngiver kun AEAD og hashen, mens nøgleudvekslingsgrupper og signaturalgoritmer forhandles som separate parametre. Et TLS 1.3-suitenavn kan derfor ikke sammenlignes med et TLS 1.2-suitenavn på lige vilkår, selvom begge optræder i samme felt i en konfigurationsfil. En revisor, der sammenligner de to strenge direkte, drager en konklusion, som protokollen ikke understøtter. Læs også den forhandlede gruppe og signaturparametrene, ellers er sammenligningen ufuldstændig.
WireGuard vælger den modsatte vej og fjerner forhandling næsten helt: protokollen fastlægger et fast algoritmesæt, så to implementeringer enten fungerer sammen eller ej. Det er et legitimt designvalg, og det betyder også, at spørgsmålet om, hvilken suite WireGuard forhandler, ikke har et svar, der er værd at sammenligne. Hvis du reviderer det, læs specifikationen én gang og revider derefter nøglehåndteringen omkring den i stedet for forhandlingen.
Laget bestemmer ordforrådet
En IPsec-udrulning forhandler to gange: et IKE-forslag til kontrolkanalen og en ESP-transform til dataene, og de to kan lovligt afvige. At læse det første og antage, at det beskriver det andet, er en almindelig kilde til forvirring under en revision, fordi konfigurationsfilen nævner begge, og den interessante er den anden.
| 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, der er tilgængeligt i ét bibliotek, er ikke automatisk implementeret til en anden datasti. Derfor er påstanden om, at vores produkt understøtter AES-256, svagere, end den lyder, og derfor løses et interoperabilitetsproblem normalt ved at finde den vedligeholdte fællesmængde i stedet for at aktivere enhver gammel algoritme på begge sider.
Specifikationen for TLS 1.3 er det klareste offentliggjorte eksempel på adskillelsen, fordi den definerer suiten som et par og flytter resten til deres egen forhandling. Når denne form er velkendt, bliver IPsec-forslaget og det ene faste WireGuard-sæt læsbare som variationer over den samme idé.
Læs det forhandlede resultat, og stop så
Et konfigureret forslag er ikke bevis på, hvad to peers valgte. Den levende session bærer svaret, og enhver almindelig implementering kan rapportere det uden at fange pakker.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showLæs i outputtet de valgte algoritmer i stedet for den tilbudte liste. Hvis svaret er svagere, end politikken tilsigtede, hører rettelsen hjemme i forslagets konfiguration på den ene eller anden side, og en uoverensstemmelse viser sig i moderne implementeringer normalt som en mislykket forhandling snarere end en tavs nedgradering.
Husk så, hvad pakken ikke dækker. Ruter, applikationstilladelser, logning og opbevaring er separate beslutninger med deres egen gennemgang, og et kompatibelt kryptografisk arrangement siger intet om nogen af dem. Chifferdiskussionen er værd at have, men den besvarer et snævrere spørgsmål end det, de fleste faktisk stiller.
Hold ordforrådet præcist, og argumentet bliver kortere. En pakke er et sæt roller på et lag, en ciffer er én komponent, og det forhandlede resultat er det eneste, der beskriver den forbindelse, du faktisk har. Alt andet i sammenligningen er dekoration.