Moet je twee VPN-lagen stapelen? Drie voorwaarden om te controleren

Voordat je een tweede versleutelingslaag aan een VPN toevoegt, beantwoord eerlijk één vraag: wat houdt de waarnemer nog vast nadat beide lagen hun werk hebben gedaan? Als het antwoord de binnenste ciphertext is, ongewijzigd, dan heeft nesting tijd gekocht en niets anders. Wat volgt is een beslissingsprocedure, geen aanbeveling. Hetzelfde diagram is verspilde CPU in de ene uitrol en het juiste antwoord in de andere, en alleen drie voorwaarden scheiden de twee.

Schrijf op wat de waarnemer bewaart

Leg het object vast dat een tegenstander vandaag kan opslaan, en dan de reeks verwijderingen die uiteindelijk platte tekst zou blootleggen. Een buitenste tunnel produceert ciphertext; als de bescherming ervan eindigt, blijft de ciphertext van de binnenste tunnel over, nog steeds verzegeld. Een omhulsel verwijderen is geen ontsleuteling. Die zin beschrijft nesting, en hij geldt alleen zolang de binnenste sleutel overleeft. Op het moment dat de twee lagen iets delen, stort de tijdlijn ineen tot één gebeurtenis.

Het nuttige artefact is dus een tijdlijn, geen diagram van dozen. Noteer voor elke laag het eindpunt, de sleuteleigenaar, de identiteitscontrole en het jaar waarin de aanname naar verwachting faalt.

Een praktische manier om je eigen bewering te testen: neem aan dat de waarnemer alles opneemt en nooit opgeeft. Onder die aanname, beschermt het ontwerp de lading nog voor de vereiste levensduur? Als het antwoord ervan afhangt dat de waarnemer kiest om geen verkeer op te slaan, heeft het ontwerp geen antwoord.

Voorwaarde één: stoppen de lagen op verschillende plaatsen?

Nesting loont wanneer de twee lagen in verschillende vertrouwensdomeinen eindigen, bijvoorbeeld een door de provider beheerde IPsec-gateway voor een tunnel op applicatieniveau die binnen je eigen netwerk eindigt. Dan levert het breken van de buitenste laag ciphertext op die alleen jouw host kan openen, en de provider ziet op geen enkel moment platte tekst. Zet beide lagen op dezelfde gateway en die eigenschap verdwijnt. Wie de doos compromitteert, leest het verkeer tussen de twee ontsleutelingsbewerkingen, hoeveel omhulsels het diagram ook toont.

Controleer dat met de geïnstalleerde toestand in plaats van het ontwerp. Op Linux somt ip xfrm state elke beveiligingsassociatie en de eindpunten ervan op, wat bepaalt waar elke laag echt stopt.

Voorwaarde twee: is het sleutelmateriaal echt onafhankelijk?

Twee lagen gebouwd uit één certificaat, één vooraf gedeelde sleutel of één leveranciersbibliotheek zijn één laag met extra stappen. Dan ontgrendelt één gecompromitteerd inloggegeven beide, en één implementatiefout verwijdert beide in één keer. Onafhankelijkheid moet zichtbaar zijn in de configuratie, niet beweerd op een dia.

Hier verslaat hybride sleutelopzet het stapelen van tunnels. IKEv2 kan meerdere sleuteluitwisselingen in één onderhandeling dragen, zodat een klassieke groep en een post-kwantum-KEM beide dezelfde sessiesleutels kunnen voeden in plaats van om elkaar heen te worden gewikkeld. Het resultaat is één beveiligingsassociatie waarvan de sleutels van beide geheimen afhangen, en een aanvaller moet beide breken. Dat is een gedocumenteerde constructie met een gedefinieerde samenstelling, wat een zelfgemaakte stapel van twee VPN-producten niet is. Op strongSwan drukt swanctl --list-sas het onderhandelde voorstel voor elke SA af, en zo bevestig je wat er echt liep in plaats van wat je hebt geconfigureerd.

Voorwaarde drie: overleven de gegevens de buitenste aanname?

Een laag die twintig jaar moet houden, heeft een argument van twintig jaar nodig. Nu opnemen en later ontsleutelen is goedkoop, en daarom kan een klassieke buitenste laag niet als tijdelijke wikkel rond iets sterkers worden behandeld.

Vraag wanneer elke sleutel herstelbaar wordt, niet of het cijfer vandaag gebroken is. Een statische sleuteluitwisseling zonder forward secrecy faalt met terugwerkende kracht op de dag dat de privésleutel valt. Efemere sleutelovereenkomst faalt alleen voor sessies die een aanvaller kan aanvallen terwijl ze leven, of wanneer het algoritme zelf verzwakt. Dat verschil bepaalt of een binnenste laag in 2040 nog helpt. Het bepaalt ook of de buitenste laag überhaupt iets verandert, want een buitenste laag met de zwakkere sleutellevensduur wordt simpelweg het vroegste punt op de tijdlijn.

Wat je in plaats daarvan bouwt als het antwoord nee is

Als een van de drie voorwaarden faalt, laat de nesting vallen en besteed de inspanning aan de laag die de levensduureis werkelijk draagt. Configureer een hybride sleuteluitwisseling in het protocol dat je al draait, houd de implementatie actueel en schrijf de samenstelling op waarop je vertrouwt. ML-KEM noemen in een ontwerpdocument is geen beveiligingseigenschap, en FIPS 203 definieert het sleutelinkapselingsmechanisme, niet je tunnel.

Waar een tweede laag zijn plek echt verdient, beschrijf het als verdediging in de diepte en niet als bewijs. Verifieer daarna de samenstelling: welk eindpunt welke sleutel houdt, welke identiteit elke kant controleert, en wat een operator met consoletoegang kan lezen. Een ontwerp dat die drie vragen overleeft, is de extra CPU waard. Een dat dat niet doet, is een diagram.

Leg voor het wijzigingsvenster de huidige SA-tabel en de onderhandelde voorstellen vast, en leg ze daarna opnieuw vast en vergelijk, want het enige bewijs dat telt is waar de apparaten het werkelijk over eens zijn geworden.