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

Før du tilføjer et andet krypteringslag til en VPN, svar ærligt på ét spørgsmål: hvad har observatøren stadig tilbage, når begge lag har gjort deres arbejde? Hvis svaret er den indre ciphertext, uændret, har nesting købt tid og intet andet. Det følgende er en beslutningsprocedure, ikke en anbefaling. Det samme diagram er spildt CPU i én udrulning og det rigtige svar i en anden, og kun tre betingelser skiller de to.

Skriv ned, hvad observatøren beholder

Registrér det objekt, en modstander kan gemme i dag, og derefter den sekvens af fjernelser, der til sidst ville blotlægge klartekst. En ydre tunnel producerer ciphertext; når dens beskyttelse slutter, er det, der er tilbage, den indre tunnels ciphertext, stadig forseglet. At fjerne en indpakning er ikke dekryptering. Den sætning beskriver nesting, og den gælder kun, så længe den indre nøgle overlever. I det øjeblik de to lag deler noget som helst, kollapser tidslinjen til en enkelt begivenhed.

Så det nyttige artefakt er en tidslinje, ikke et diagram af kasser. For hvert lag skriv endepunktet, nøgleejeren, identitetskontrollen og det år, hvor antagelsen forventes at svigte.

En praktisk måde at teste din egen påstand: antag, at observatøren registrerer alt og aldrig giver op. Under den antagelse, beskytter designet stadig nyttelasten i den krævede levetid? Hvis svaret afhænger af, at observatøren vælger ikke at gemme trafik, har designet intet svar.

Betingelse et: stopper lagene forskellige steder?

Nesting betaler sig, når de to lag terminerer i forskellige tillidsdomæner, for eksempel en udbyderstyret IPsec-gateway foran en tunnel på applikationsniveau, der slutter inde i dit eget netværk. Så giver brud på det ydre lag ciphertext, som kun din host kan åbne, og udbyderen ser aldrig klartekst på noget tidspunkt. Sæt begge lag på samme gateway, og den egenskab forsvinder. Den, der kompromitterer kassen, læser trafikken mellem de to dekrypteringsoperationer, uanset hvor mange indpakninger diagrammet viser.

Kontrollér det med den installerede tilstand frem for designet. På Linux viser ip xfrm state hver sikkerhedsassociation og dens endepunkter, hvilket afgør, hvor hvert lag faktisk stopper.

Betingelse to: er nøglematerialet faktisk uafhængigt?

To lag bygget af ét certifikat, én forudelt nøgle eller ét leverandørbibliotek er ét lag med ekstra trin. Så låser ét kompromitteret credential begge op, og én implementeringsfejl fjerner begge på én gang. Uafhængigheden skal være synlig i konfigurationen, ikke hævdet på et slide.

Det er her, hybrid nøgleetablering slår stabling af tunneler. IKEv2 kan bære flere nøgleudvekslinger i én forhandling, så en klassisk gruppe og en post-kvante-KEM begge kan føde de samme sessionsnøgler i stedet for at blive viklet om hinanden. Resultatet er én sikkerhedsassociation, hvis nøgler afhænger af begge hemmeligheder, og en angriber skal bryde begge. Det er en dokumenteret konstruktion med en defineret sammensætning, hvilket en hjemmelavet stak af to VPN-produkter ikke er. På strongSwan udskriver swanctl --list-sas det forhandlede forslag for hver SA, og det er sådan, du bekræfter, hvad der kørte, frem for hvad du konfigurerede.

Betingelse tre: overlever dataene den ydre antagelse?

Et lag, der skal holde i tyve år, har brug for et tyveårigt argument. At optage nu og dekryptere senere er billigt, og det er grunden til, at et klassisk ydre lag ikke kan behandles som en midlertidig indpakning omkring noget stærkere.

Spørg, hvornår hver nøgle bliver genoprettelig, ikke om cipheren er brudt i dag. En statisk nøgleudveksling uden forward secrecy fejler bagudrettet den dag, den private nøgle falder. Ephemeral nøgleaftale fejler kun for sessioner, som en angriber kan angribe, mens de er live, eller når algoritmen selv svækkes. Den forskel afgør, om et indre lag stadig hjælper i 2040. Den afgør også, om det ydre lag ændrer noget som helst, fordi et ydre lag med den svagere nøglelevetid simpelthen bliver det tidligste punkt på tidslinjen.

Hvad du i stedet skal bygge, når svaret er nej

Hvis nogen af de tre betingelser svigter, drop nesting og brug kræfterne på det lag, der faktisk bærer levetidskravet. Konfigurér en hybrid nøgleudveksling i den protokol, du allerede kører, hold implementeringen opdateret, og skriv den sammensætning ned, du stoler på. At nævne ML-KEM i et designdokument er ikke en sikkerhedsegenskab, og FIPS 203 definerer nøgleindkapslingsmekanismen, ikke din tunnel.

Hvor et andet lag virkelig fortjener sin plads, beskriv det som forsvar i dybden frem for som et bevis. Bekræft derefter sammensætningen: hvilket endepunkt holder hvilken nøgle, hvilken identitet hver side kontrollerer, og hvad en operatør med konsoladgang kan læse. Et design, der overlever de tre spørgsmål, er den ekstra CPU værd. Et, der ikke gør, er et diagram.

Før ændringsvinduet, registrér den aktuelle SA-tabel og de forhandlede forslag, og efter det registrér dem igen og sammenlign, fordi det eneste bevis, der betyder noget, er, hvad enhederne faktisk blev enige om.