Bör du stapla två VPN-lager? Tre villkor att kontrollera

Innan du lägger till ett andra krypteringslager i en VPN, svara ärligt på en fråga: vad har observatören kvar när båda lagren har gjort sitt? Om svaret är den inre chiffertexten, oförändrad, har nästlingen köpt tid och inget annat. Det som följer är ett beslutsförfarande, inte en rekommendation. Samma diagram är bortkastad CPU i en utrullning och rätt svar i en annan, och bara tre villkor skiljer de två.

Skriv ned vad observatören behåller

Registrera objektet som en motståndare kan lagra i dag, och sedan sekvensen av borttagningar som till slut skulle avslöja klartext. En yttre tunnel producerar chiffertext; när dess skydd tar slut är det som återstår den inre tunnelns chiffertext, fortfarande förseglad. Att ta bort ett hölje är inte dekryptering. Den meningen beskriver nästling, och den gäller bara så länge den inre nyckeln överlever. I samma ögonblick som de två lagren delar något som helst kollapsar tidslinjen till en enda händelse.

Så den användbara artefakten är en tidslinje, inte ett diagram av lådor. Skriv för varje lager ned slutpunkten, nyckelägaren, identitetskontrollen och året då antagandet förväntas fallera.

Ett praktiskt sätt att testa ditt eget påstående: anta att observatören registrerar allt och aldrig ger upp. Under det antagandet, skyddar designen fortfarande nyttolasten under den krävda livslängden? Om svaret beror på att observatören väljer att inte lagra trafik har designen inget svar.

Villkor ett: stannar lagren på olika ställen?

Nästling lönar sig när de två lagren slutar i olika förtroendedomäner, till exempel en leverantörsstyrd IPsec-gateway framför en tunnel på applikationsnivå som slutar inne i ditt eget nätverk. Då ger brytning av det yttre lagret chiffertext som bara din värd kan öppna, och leverantören ser aldrig klartext vid någon tidpunkt. Sätt båda lagren på samma gateway och den egenskapen försvinner. Den som komprometterar lådan läser trafiken mellan de två dekrypteringsoperationerna, oavsett hur många höljen diagrammet visar.

Kontrollera det med det installerade tillståndet i stället för designen. På Linux listar ip xfrm state varje säkerhetsassociation och dess slutpunkter, vilket avgör var varje lager faktiskt stannar.

Villkor två: är nyckelmaterialet verkligen oberoende?

Två lager byggda av ett enda certifikat, en enda fördelad nyckel eller ett enda leverantörsbibliotek är ett lager med extra steg. Då låser en enda komprometterad autentiseringsuppgift upp båda, och ett enda implementeringsfel tar bort båda på en gång. Oberoendet måste vara synligt i konfigurationen, inte påstått på en bild.

Här slår hybrid nyckeletablering stapling av tunnlar. IKEv2 kan bära flera nyckelutbyten i en enda förhandling, så en klassisk grupp och en post-kvant-KEM kan båda mata samma sessionsnycklar i stället för att lindas runt varandra. Resultatet är en enda säkerhetsassociation vars nycklar beror på båda hemligheterna, och en angripare måste bryta båda. Det är en dokumenterad konstruktion med en definierad sammansättning, vilket en hemmabyggd stapel av två VPN-produkter inte är. På strongSwan skriver swanctl --list-sas ut det förhandlade förslaget för varje SA, och så bekräftar du vad som faktiskt körde, inte vad du konfigurerade.

Villkor tre: överlever data det yttre antagandet?

Ett lager som måste hålla i tjugo år behöver ett tjugoårigt argument. Att spela in nu och dekryptera senare är billigt, och det är därför ett klassiskt yttre lager inte kan behandlas som ett tillfälligt hölje runt något starkare.

Fråga när varje nyckel blir återställbar, inte om chiffern är bruten i dag. Ett statiskt nyckelutbyte utan framåtsekretess misslyckas retroaktivt den dag den privata nyckeln faller. Ephemeral nyckelöverenskommelse misslyckas bara för sessioner som en angripare kan attackera medan de är levande, eller när algoritmen själv försvagas. Den skillnaden avgör om ett inre lager fortfarande hjälper 2040. Den avgör också om det yttre lagret ändrar något alls, eftersom ett yttre lager med den svagare nyckellivslängden helt enkelt blir den tidigaste punkten på tidslinjen.

Vad du i stället bör bygga när svaret är nej

Om något av de tre villkoren fallerar, släpp nästlingen och lägg kraften på det lager som faktiskt bär livslängdskravet. Konfigurera ett hybridnyckelutbyte i protokollet du redan kör, håll implementeringen uppdaterad och skriv ned sammansättningen du förlitar dig på. Att nämna ML-KEM i ett designdokument är inte en säkerhetsegenskap, och FIPS 203 definierar nyckelinkapslingsmekanismen, inte din tunnel.

Där ett andra lager verkligen förtjänar sin plats, beskriv det som försvar på djupet och inte som ett bevis. Kontrollera sedan sammansättningen: vilken slutpunkt som håller vilken nyckel, vilken identitet varje sida kontrollerar, och vad en operatör med konsolåtkomst kan läsa. En design som överlever de tre frågorna är den extra CPU:n värd. En som inte gör det är ett diagram.

Före ändringsfönstret, registrera den aktuella SA-tabellen och de förhandlade förslagen, och efteråt registrera dem igen och jämför, eftersom det enda beviset som betyder något är vad enheterna faktiskt enades om.