Bør du stable to VPN-lag? Tre betingelser å kontrollere

Før du legger til et andre krypteringslag i en VPN, svar ærlig på ett spørsmål: hva har observatøren fortsatt igjen når begge lagene har gjort jobben sin? Hvis svaret er den indre ciphertexten, uendret, har nesting kjøpt tid og ingenting annet. Det som følger, er en beslutningsprosedyre, ikke en anbefaling. Det samme diagrammet er bortkastet CPU i én utrulling og det riktige svaret i en annen, og bare tre betingelser skiller de to.

Skriv ned hva observatøren beholder

Registrer objektet en motstander kan lagre i dag, og deretter sekvensen av fjerninger som til slutt ville avdekke klartekst. En ytre tunnel produserer ciphertext; når beskyttelsen tar slutt, er det som er igjen den indre tunnelens ciphertext, fortsatt forseglet. Å fjerne en innpakning er ikke dekryptering. Den setningen beskriver nesting, og den gjelder bare så lenge den indre nøkkelen overlever. I det øyeblikket de to lagene deler noe som helst, kollapser tidslinjen til én enkelt hendelse.

Så det nyttige artefaktet er en tidslinje, ikke et diagram av bokser. For hvert lag skriver du endepunktet, nøkkeleieren, identitetskontrollen og året antagelsen forventes å svikte.

En praktisk måte å teste din egen påstand: anta at observatøren registrerer alt og aldri gir opp. Under den antagelsen, beskytter designet fortsatt nyttelasten i den påkrevde levetiden? Hvis svaret avhenger av at observatøren velger å ikke lagre trafikk, har designet ikke noe svar.

Betingelse én: stopper lagene på forskjellige steder?

Nesting lønner seg når de to lagene terminerer i forskjellige tillitsdomener, for eksempel en leverandørstyrt IPsec-gateway foran en tunnel på applikasjonsnivå som ender inne i ditt eget nettverk. Da gir brudd på det ytre laget ciphertext som bare din vert kan åpne, og leverandøren ser aldri klartekst på noe tidspunkt. Sett begge lagene på samme gateway, og den egenskapen forsvinner. Den som kompromitterer boksen, leser trafikken mellom de to dekrypteringsoperasjonene, uansett hvor mange innpakninger diagrammet viser.

Kontroller det med den installerte tilstanden i stedet for designet. På Linux lister ip xfrm state hver sikkerhetsassosiasjon og endepunktene dens, noe som avgjør hvor hvert lag faktisk stopper.

Betingelse to: er nøkkelmaterialet faktisk uavhengig?

To lag bygget av ett sertifikat, én forhåndsdelt nøkkel eller ett leverandørbibliotek er ett lag med ekstra trinn. Da låser én kompromittert legitimasjon opp begge, og én implementeringsfeil fjerner begge på en gang. Uavhengigheten må være synlig i konfigurasjonen, ikke hevdet på en lysbilde.

Det er her hybrid nøkkeloppsett slår stabling av tunneler. IKEv2 kan bære flere nøkkelutvekslinger i én forhandling, så en klassisk gruppe og en post-kvante-KEM kan begge mate de samme sesjonsnøklene i stedet for å bli viklet rundt hverandre. Resultatet er én sikkerhetsassosiasjon der nøklene avhenger av begge hemmelighetene, og en angriper må bryte begge. Det er en dokumentert konstruksjon med en definert sammensetning, noe en hjemmelaget stabel av to VPN-produkter ikke er. På strongSwan skriver swanctl --list-sas ut det forhandlede forslaget for hver SA, og slik bekrefter du hva som faktisk kjørte, ikke hva du konfigurerte.

Betingelse tre: overlever dataene den ytre antagelsen?

Et lag som må holde i tjue år trenger et tjueårig argument. Å ta opp nå og dekryptere senere er billig, og det er grunnen til at et klassisk ytre lag ikke kan behandles som en midlertidig innpakning rundt noe sterkere.

Spør når hver nøkkel blir gjenopprettbar, ikke om chifferen er brutt i dag. En statisk nøkkelutveksling uten forward secrecy feiler bakoverrettet den dagen den private nøkkelen faller. Ephemeral nøkkelavtale feiler bare for økter en angriper kan angripe mens de er levende, eller når algoritmen selv svekkes. Den forskjellen avgjør om et indre lag fortsatt hjelper i 2040. Den avgjør også om det ytre laget endrer noe som helst, fordi et ytre lag med den svakere nøkkellevetiden rett og slett blir det tidligste punktet på tidslinjen.

Hva du i stedet bør bygge når svaret er nei

Hvis noen av de tre betingelsene svikter, dropp nesting og bruk kreftene på laget som faktisk bærer levetidskravet. Konfigurer en hybrid nøkkelutveksling i protokollen du allerede kjører, hold implementeringen oppdatert, og skriv ned sammensetningen du er avhengig av. Å nevne ML-KEM i et designdokument er ikke en sikkerhetsegenskap, og FIPS 203 definerer nøkkelinnkapslingsmekanismen, ikke tunnelen din.

Der et andre lag virkelig fortjener plassen sin, beskriv det som forsvar i dybden i stedet for som et bevis. Kontroller deretter sammensetningen: hvilket endepunkt som holder hvilken nøkkel, hvilken identitet hver side kontrollerer, og hva en operatør med konsolltilgang kan lese. Et design som overlever de tre spørsmålene, er den ekstra CPU-en verdt. Et som ikke gjør det, er et diagram.

Før endringsvinduet, registrer gjeldende SA-tabell og de forhandlede forslagene, og etterpå registrer dem igjen og sammenlign, fordi det eneste beviset som betyr noe, er hva enhetene faktisk ble enige om.