Érdemes két VPN-réteget egymásra rakni? Három feltétel ellenőrzésre

Mielőtt második titkosítási réteget ad hozzá egy VPN-hez, válaszoljon őszintén egy kérdésre: mi marad még a megfigyelő birtokában, miután mindkét réteg elvégezte a dolgát? Ha a válasz a belső rejtjelszöveg, változatlanul, akkor a beágyazás időt vásárolt, és semmi mást. Ami következik, az döntési eljárás, nem ajánlás. Ugyanaz a diagram az egyik telepítésben elpazarolt processzor, a másikban a helyes válasz, és csak három feltétel választja el a kettőt.

Írja le, mit tart meg a megfigyelő

Rögzítse azt az objektumot, amelyet egy támadó ma tárolhat, majd az eltávolítások sorozatát, amely végül feltárná a nyílt szöveget. Egy külső alagút rejtjelszöveget állít elő; amikor a védelme véget ér, ami marad, az a belső alagút rejtjelszövege, továbbra is lezárva. Egy burkolat eltávolítása nem visszafejtés. Ez a mondat írja le a beágyazást, és csak addig érvényes, amíg a belső kulcs túlél. Abban a pillanatban, amikor a két réteg bármit megoszt, az idővonal egyetlen eseménnyé omlik össze.

Tehát a hasznos artefaktum egy idővonal, nem dobozok diagramja. Minden réteghez írja le a végpontot, a kulcs tulajdonosát, az identitásellenőrzést és azt az évet, amikor a feltevés várhatóan megbukik.

Gyakorlati mód a saját állítás tesztelésére: tegye fel, hogy a megfigyelő mindent rögzít, és soha nem adja fel. E feltevés mellett a tervezés még védi-e a hasznos terhelést a szükséges élettartam alatt? Ha a válasz attól függ, hogy a megfigyelő úgy dönt, nem tárol forgalmat, a tervezésnek nincs válasza.

Első feltétel: különböző helyeken állnak meg a rétegek?

A beágyazás akkor éri meg, ha a két réteg különböző bizalmi tartományokban végződik, például egy szolgáltató által kezelt IPsec-átjáró előtt egy alkalmazásszintű alagút, amely az Ön saját hálózatán belül végződik. Ekkor a külső réteg feltörése olyan rejtjelszöveget ad, amelyet csak az Ön gazdagépe nyithat meg, és a szolgáltató soha nem lát nyílt szöveget. Tegye mindkét réteget ugyanarra az átjáróra, és ez a tulajdonság eltűnik. Aki feltöri a dobozt, az a két visszafejtési művelet közötti forgalmat olvassa, bármennyi burkolatot is mutat a diagram.

Ezt a telepített állapottal ellenőrizze, nem a tervezéssel. Linuxon az ip xfrm state felsorol minden biztonsági társítást és annak végpontjait, ami eldönti, hol áll meg valójában az egyes rétegek.

Második feltétel: valóban független a kulcsanyag?

Két réteg, amely egyetlen tanúsítványból, egyetlen előre megosztott kulcsból vagy egyetlen szállítói könyvtárból épül, egy réteg extra lépésekkel. Ilyenkor egyetlen kompromittált hitelesítő adat mindkettőt kinyitja, és egyetlen implementációs hiba mindkettőt egyszerre távolítja el. A függetlenségnek a konfigurációban láthatónak kell lennie, nem diákon hangoztatottnak.

Itt a hibrid kulcslétesítés legyőzi az alagutak egymásra rakását. Az IKEv2 egyetlen tárgyalásban több kulcscserét is hordozhat, így egy klasszikus csoport és egy poszt-kvantum KEM is ugyanazokat a munkamenet-kulcsokat táplálhatja, ahelyett hogy egymás köré tekerednének. Az eredmény egyetlen biztonsági társítás, amelynek kulcsai mindkét titoktól függnek, és a támadónak mindkettőt fel kell törnie. Ez dokumentált, meghatározott összetételű konstrukció, ami egy két VPN-termékből álló házilagos halom nem. A strongSwanban a swanctl --list-sas kiírja a tárgyalt javaslatot minden SA-hoz, és így igazolja, hogy mi futott valójában, nem pedig azt, hogy mit állított be.

Harmadik feltétel: túlélik-e az adatok a külső feltevést?

Egy rétegnek, amelynek húsz évig kell kitartania, húszéves érvre van szüksége. Most rögzíteni és később visszafejteni olcsó, és ezért nem kezelhető egy klasszikus külső réteg ideiglenes burkolatként valami erősebb körül.

Kérdezze meg, mikor válik minden kulcs helyreállíthatóvá, ne azt, hogy a rejtjel ma feltört-e. Az előremutató titoktartás nélküli statikus kulcscsere visszamenőleg bukik meg azon a napon, amikor a privát kulcs elesik. Az efemer kulcsmegállapodás csak azoknál a munkameneteknél bukik meg, amelyeket a támadó élő állapotukban támadhat, vagy amikor maga az algoritmus gyengül. Ez a különbség dönti el, hogy egy belső réteg 2040-ben még segít-e. Azt is eldönti, hogy a külső réteg egyáltalán változtat-e valamit, mert a gyengébb kulcsélettartamú külső réteg egyszerűen az idővonal legkorábbi pontjává válik.

Mit építsen helyette, ha a válasz nem

Ha a három feltétel bármelyike megbukik, hagyja el a beágyazást, és a fáradságot arra a rétegre fordítsa, amely valóban hordozza az élettartam-követelményt. Állítson be hibrid kulcscserét abban a protokollban, amelyet már futtat, tartsa naprakészen az implementációt, és írja le azt az összetételt, amelyre támaszkodik. Az ML-KEM megnevezése egy tervezési dokumentumban nem biztonsági tulajdonság, és a FIPS 203 a kulcsbefoglalási mechanizmust határozza meg, nem az alagútját.

Ahol egy második réteg valóban kiérdemli a helyét, mélységi védelemként írja le, nem bizonyítékként. Ezután ellenőrizze az összetételt: melyik végpont melyik kulcsot tartja, milyen identitást ellenőriz mindkét oldal, és mit olvashat egy konzolhozzáféréssel rendelkező üzemeltető. Egy tervezés, amely kiállja ezt a három kérdést, megéri az extra processzort. Amelyik nem, az csak egy diagram.

A változási ablak előtt rögzítse az aktuális SA-táblát és a tárgyalt javaslatokat, utána rögzítse újra őket, és hasonlítsa össze, mert az egyetlen bizonyíték, amely számít, az, amiben az eszközök valóban megegyeztek.