Bør du stabla to VPN-lag? Tre vilkår å kontrollera

Før du legg til eit andre krypteringslag i ein VPN, svar ærleg på eitt spørsmål: kva sit observatøren att med når begge laga har gjort jobben sin? Viss svaret er den indre cipherteksten, uendra, har nesting kjøpt tid og ingenting anna. Det som følgjer, er ein beslutningsprosedyre, ikkje ei tilråding. Det same diagrammet er bortkasta CPU i éin utrulling og det rette svaret i ei anna, og berre tre vilkår skil dei to.

Skriv ned kva observatøren held på

Registrer objektet ein motstandar kan lagra i dag, og deretter sekvensen av fjerningar som til slutt ville avdekkja klartekst. Ein ytre tunnel produserer ciphertekst; når vernet hans tek slutt, er det som er att den indre tunnelen sin ciphertekst, framleis forsegla. Å fjerna ei innpakning er ikkje dekryptering. Den setninga skildrar nesting, og ho gjeld berre så lenge den indre nøkkelen overlever. I det augneblinken dei to laga deler noko som helst, kollapsar tidslinja til éi enkel hending.

Så det nyttige artefaktet er ei tidslinje, ikkje eit diagram av boksar. For kvart lag skriv du endepunktet, nøkkoleigaren, identitetskontrollen og året antakinga er venta å svikta.

Ein praktisk måte å testa din eigen påstand: gå ut frå at observatøren registrerer alt og aldri gir opp. Under den antakinga, vernar designet framleis nyttelasta i den påkravde levetida? Viss svaret avheng av at observatøren vel å ikkje lagra trafikk, har designet ikkje noko svar.

Vilkår éin: stoppar laga på ulike stader?

Nesting løner seg når dei to laga terminerer i ulike tillitsdomene, til dømes ein leverandørstyrt IPsec-gateway framfor ein tunnel på applikasjonsnivå som endar inne i ditt eige nettverk. Då gir brot på det ytre laget ciphertekst som berre verten din kan opna, og leverandøren ser aldri klartekst på noko tidspunkt. Set begge laga på same gateway, og den eigenskapen forsvinn. Den som kompromitterer boksen, les trafikken mellom dei to dekrypteringsoperasjonane, uansett kor mange innpakningar diagrammet viser.

Kontroller det med den installerte tilstanden i staden for designet. På Linux listar ip xfrm state kvar tryggleiksassosiasjon og endepunkta hans, noko som avgjer kvar kvart lag faktisk stoppar.

Vilkår to: er nøkkelmaterialet faktisk uavhengig?

To lag bygde av eitt sertifikat, éin førehandsdel nøkkel eller eitt leverandørbibliotek er eitt lag med ekstra trinn. Då låser éin kompromittert legitimasjon opp begge, og éin implementasjonsfeil fjernar begge på ein gong. Uavhengigheita må vera synleg i konfigurasjonen, ikkje påstått på ein lysbilete.

Det er her hybrid nøkkeloppsett slår stabling av tunnelar. IKEv2 kan bera fleire nøkkelutvekslingar i éin forhandling, så ein klassisk gruppe og ein post-kvante-KEM kan begge fø dei same sesjonsnøklane i staden for å bli vikla rundt kvarandre. Resultatet er éin tryggleiksassosiasjon der nøklane avheng av begge hemmelegheitene, og ein åtakar må bryta begge. Det er ein dokumentert konstruksjon med ein definert samansetning, noko ein heimelaga stabel av to VPN-produkt ikkje er. På strongSwan skriv swanctl --list-sas ut det forhandla forslaget for kvar SA, og slik stadfester du kva som faktisk køyrde, ikkje kva du konfigurerte.

Vilkår tre: overlever dataa den ytre antakinga?

Eit lag som må halda i tjue år treng eit tjueårig argument. Å ta opp no og dekryptera seinare er billeg, og det er grunnen til at eit klassisk ytre lag ikkje kan handsamast som ei mellombels innpakning rundt noko sterkare.

Spør når kvar nøkkel blir gjenopprettbar, ikkje om chifferen er broten i dag. Ein statisk nøkkelutveksling utan forward secrecy feilar bakoverretta den dagen den private nøkkelen fell. Ephemeral nøkkelavtale feilar berre for økter ein åtakar kan åtaka medan dei er levande, eller når algoritmen sjølv blir svakare. Den skilnaden avgjer om eit indre lag framleis hjelper i 2040. Han avgjer også om det ytre laget endrar noko som helst, fordi eit ytre lag med den svakare nøkkellevetida rett og slett blir det tidlegaste punktet på tidslinja.

Kva du i staden bør byggja når svaret er nei

Viss noko av dei tre vilkåra sviktar, dropp nesting og bruk kreftene på laget som faktisk ber levetidskravet. Konfigurer ein hybrid nøkkelutveksling i protokollen du allereie køyrer, hald implementasjonen oppdatert, og skriv ned samansetninga du er avhengig av. Å nemna ML-KEM i eit designdokument er ikkje ein tryggleikseigenskap, og FIPS 203 definerer nøkkelinnkapslingsmekanismen, ikkje tunnelen din.

Der eit andre lag verkeleg fortener plassen sin, skildra det som forsvar i djupna i staden for som eit prov. Kontroller deretter samansetninga: kva endepunkt som held kva nøkkel, kva identitet kvar side kontrollerer, og kva ein operatør med konsolltilgang kan lesa. Eit design som overlever dei tre spørsmåla, er den ekstra CPU-en verdt. Eit som ikkje gjer det, er eit diagram.

Før endringsvindauget, registrer gjeldande SA-tabell og dei forhandla forslaga, og etterpå registrer dei igjen og samanlikn, fordi det einaste provet som betyr noko, er kva einingane faktisk vart samde om.