Moet jy twee VPN-lae op mekaar stapel? Drie voorwaardes om na te gaan
Twee VPN-lae help net as hulle by verskillende gashere eindig en onafhanklike sleutels gebruik. Drie voorwaardes bepaal of nestel sekuriteit byvoeg of net CPU-koste.
Voordat jy 'n tweede enkripsielaag by 'n VPN voeg, beantwoord een vraag eerlik: wat hou die waarnemer steeds in die hand nadat albei lae hulle werk gedoen het? As die antwoord die binneste chifferteks is, onveranderd, dan het nestel tyd gekoop en niks anders nie. Wat volg is 'n besluitproses, nie 'n aanbeveling nie. Dieselfde diagram is vermorste CPU in een ontplooiing en die regte antwoord in 'n ander, en net drie voorwaardes skei die twee.
Skryf neer wat die waarnemer behou
Teken die objek aan wat 'n aanvaller vandag kan stoor, en dan die reeks verwyderings wat uiteindelik die gewone teks sou blootle. 'n Buitenste tonnel lewer chifferteks; wanneer sy beskerming eindig, is wat oorbly die binneste tonnel se chifferteks, steeds verseel. Om 'n omhulsel te verwyder is nie ontsyfering nie. Daardie sin beskryf nestel, en dit geld net solank die binneste sleutel oorleef. Die oomblik wanneer die twee lae enigiets deel, val die tydlyn in 'n enkele gebeurtenis inmekaar.
Dus is die nuttige artefak 'n tydlyn, nie 'n diagram van blokkies nie. Vir elke laag, skryf die eindpunt, die sleutel-eienaar, die identiteitskontrole en die jaar waarin die aanname na verwagting gaan faal.
'n Praktiese manier om jou eie bewering te toets: neem aan die waarnemer teken alles aan en gee nooit op nie. Onder daardie aanname, beskerm die ontwerp steeds die vrag vir sy vereiste leeftyd? As die antwoord daarvan afhang dat die waarnemer kies om nie verkeer te stoor nie, het die ontwerp geen antwoord nie.
Voorwaarde een: stop die lae op verskillende plekke?
Nestel loon wanneer die twee lae in verskillende vertrouensdomeine eindig, byvoorbeeld 'n verskaffer-bestuurde IPsec-poort voor 'n toepassingsvlak-tonnel wat binne jou eie netwerk eindig. Om die buitenste laag te breek lewer dan chifferteks wat net jou gasheer kan oopmaak, en die verskaffer sien op geen punt gewone teks nie. Plaas albei lae op dieselfde poort en daardie eienskap verdwyn. Wie die boks compromitteer, lees die verkeer tussen die twee ontsyferingsbewerkings, maak nie saak hoeveel omhulsels die diagram wys nie.
Kontroleer dit met die geïnstalleerde toestand eerder as die ontwerp. Op Linux lys ip xfrm state elke sekuriteitsassosiasie en sy eindpunte, wat beslis waar elke laag werklik stop.
Voorwaarde twee: is die sleutelmateriaal werklik onafhanklik?
Twee lae gebou uit een sertifikaat, een vooraf-gedeelde sleutel of een verskaffer-biblioteek is een laag met ekstra stappe. 'n Enkele gesteelde credensiaal ontsluit dan albei, en 'n enkele implementeringsfout verwyder albei gelyktydig. Onafhanklikheid moet in die konfigurasie sigbaar wees, nie op 'n skyfie beweer word nie.
Dit is waar hibriede sleutelvestiging beter vaar as om tonnels te stapel. IKEv2 kan verskeie sleuteluitruilings in een onderhandeling dra, sodat 'n klassieke groep en 'n post-kwantum KEM albei dieselfde sessiesleutels kan voed eerder as om om mekaar gedraai te word. Die resultaat is een sekuriteitsassosiasie wie se sleutels van albei geheime afhang, en 'n aanvaller moet albei breek. Dit is 'n gedokumenteerde konstruksie met 'n gedefinieerde samestelling, wat 'n selfgemaakte stapel van twee VPN-produkte nie is nie. Op strongSwan druk swanctl --list-sas die onderhandelde voorstel vir elke SA, wat is hoe jy bevestig wat geloop het eerder as wat jy gekonfigureer het.
Voorwaarde drie: oorleef die data die buitenste aanname?
'n Laag wat twintig jaar moet hou, het 'n twintig-jaar-argument nodig. Nou opneem en later ontsyfer is goedkoop, en dit is die rede waarom 'n klassieke buitenste laag nie as 'n tydelike omhulsel rondom iets sterker behandel kan word nie.
Vra wanneer elke sleutel herwinbaar word, nie of die syfer vandag gebreek is nie. 'n Statiese sleuteluitruiling sonder vorentoe-geheimhouding faal terugwerkend op die dag wat die private sleutel val. Efemere sleutelooreenkoms faal net vir sessies wat 'n aanvaller kan aanval terwyl hulle lewendig is, of wanneer die algoritme self verswak. Daardie verskil besluit of 'n binneste laag in 2040 nog help. Dit besluit ook of die buitenste laag enigiets verander, want 'n buitenste laag met die swakker sleutelleeftyd word bloot die vroegste punt op die tydlyn.
Wat om eerder te bou wanneer die antwoord nee is
As enige van die drie voorwaardes faal, laat vaar die nestel en spandeer die moeite op die laag wat werklik die leeftydvereiste dra. Konfigureer 'n hibriede sleuteluitruiling in die protokol wat jy reeds hardloop, hou die implementering byderhand, en skryf die samestelling neer waarop jy staatmaak. Om ML-KEM in 'n ontwerpdocument te noem is nie 'n sekuriteitseienskap nie, en FIPS 203 definieer die sleutel-inkapselingsmeganisme, nie jou tonnel nie.
Waar 'n tweede laag werklik sy plek verdien, beskryf dit as verdediging in die diepte eerder as as 'n bewys. Verifieer dan die samestelling: watter eindpunt watter sleutel hou, watter identiteit elke kant kontroleer, en wat 'n operateur met konsoltoegang kan lees. 'n Ontwerp wat daardie drie vrae oorleef, is die ekstra CPU werd. Een wat dit nie doen nie, is 'n diagram.
Voor die veranderingsvenster neem die huidige SA-tabel en die onderhandelde voorstelle vas, en daarna neem hulle weer vas en vergelyk, want die enigste bewys wat saak maak is waartoe die toestelle werklik ooreengekom het.