Cal apilar dues capes de VPN? Tres condicions per comprovar-ho

Abans d'afegir una segona capa de xifratge a una VPN, responeu honestament una pregunta: què conserva encara l'observador després que les dues capes hagin fet la seva feina? Si la resposta és el text xifrat intern, sense canvis, aleshores l'anidament ha comprat temps i res més. El que segueix és un procediment de decisió, no una recomanació. El mateix diagrama és CPU malgastada en un desplegament i la resposta correcta en un altre, i només tres condicions separen les dues coses.

Anoteu què conserva l'observador

Anoteu l'objecte que un adversari pot emmagatzemar avui, i després la seqüència de retirades que finalment exposarien el text en clar. Un túnel exterior produeix text xifrat; quan la seva protecció acaba, el que queda és el text xifrat del túnel interior, encara segellat. Treure una embolcall no és desxifrar. Aquesta frase descriu l'anidament, i només és certa mentre la clau interior sobreviu. En el moment que les dues capes comparteixen qualsevol cosa, la línia temporal es col·lapsa en un sol esdeveniment.

Així, l'artefacte útil és una línia temporal, no un diagrama de caixes. Per a cada capa, anoteu el punt final, el propietari de la clau, la comprovació d'identitat i l'any en què s'espera que falli la suposició.

Una manera pràctica de provar la vostra pròpia afirmació: suposeu que l'observador ho enregistra tot i no es rendeix mai. Sota aquesta suposició, el disseny encara protegeix la càrrega útil durant la vida útil requerida? Si la resposta depèn que l'observador triï no emmagatzemar el trànsit, el disseny no té resposta.

Condició primera: les capes acaben en llocs diferents?

L'anidament compensa quan les dues capes acaben en dominis de confiança diferents, per exemple una passarel·la IPsec gestionada pel proveïdor davant d'un túnel a nivell d'aplicació que acaba dins de la vostra xarxa. Llavors, trencar la capa exterior dona text xifrat que només el vostre amfitrió pot obrir, i el proveïdor no veu mai el text en clar. Poseu les dues capes a la mateixa passarel·la i aquesta propietat desapareix. Qui compromet la caixa llegeix el trànsit entre les dues operacions de desxifrat, per molts embolcalls que mostri el diagrama.

Comproveu-ho amb l'estat instal·lat i no amb el disseny. A Linux, ip xfrm state llista cada associació de seguretat i els seus punts finals, cosa que determina on s'atura realment cada capa.

Condició segona: el material de clau és realment independent?

Dues capes construïdes amb un sol certificat, una sola clau prèviament compartida o una sola biblioteca de proveïdor són una capa amb passos extra. Llavors una sola credencial compromesa obre les dues, i un sol error d'implementació elimina les dues alhora. La independència ha de ser visible a la configuració, no afirmada en una diapositiva.

Aquí l'establiment híbrid de claus supera l'apilament de túnels. IKEv2 pot portar diverses intercanvis de claus en una negociació, de manera que un grup clàssic i un KEM postquàntic poden alimentar les mateixes claus de sessió en lloc d'embolcallar-se l'un a l'altre. El resultat és una sola associació de seguretat les claus de la qual depenen dels dos secrets, i l'atacant ha de trencar tots dos. Aquesta és una construcció documentada amb una composició definida, cosa que no és un apilament casolà de dos productes VPN. A strongSwan, swanctl --list-sas imprimeix la proposta negociada per a cada SA, i així confirmeu què ha funcionat realment i no què heu configurat.

Condició tercera: les dades sobreviuen a la suposició exterior?

Una capa que ha de durar vint anys necessita un argument de vint anys. Enregistrar ara i desxifrar més tard és barat, i és la raó per la qual una capa exterior clàssica no es pot tractar com un embolcall temporal al voltant d'alguna cosa més forta.

Pregunteu quan es torna recuperable cada clau, no si el xifratge està trencat avui. Un intercanvi de claus estàtic sense secreció cap endavant falla retroactivament el dia que cau la clau privada. L'acord de claus efímer falla només per a les sessions que un adversari pot atacar mentre són vives, o quan l'algoritme mateix s'afebleix. Aquesta diferència decideix si una capa interior encara ajuda el 2040. També decideix si la capa exterior canvia res en absolut, perquè una capa exterior amb la vida de clau més feble simplement es converteix en el punt més primerenc de la línia temporal.

Què construir en lloc d'això quan la resposta és no

Si falla qualsevol de les tres condicions, deixeu l'anidament i gasteu l'esforç en la capa que realment porta el requisit de vida útil. Configureu un intercanvi de claus híbrid en el protocol que ja feu servir, manteniu la implementació al dia i anoteu la composició en què confieu. Anomenar ML-KEM en un document de disseny no és una propietat de seguretat, i FIPS 203 defineix el mecanisme d'encapsulament de claus, no el vostre túnel.

On una segona capa realment es guanya el lloc, descriviu-la com a defensa en profunditat i no com a prova. Després verifiqueu la composició: quin punt final té quina clau, quina identitat comprova cada costat i què pot llegir un operador amb accés a la consola. Un disseny que sobreviu a aquestes tres preguntes val la CPU extra. Un que no ho fa és un diagrama.

Abans de la finestra de canvi, captureu la taula SA actual i les propostes negociades, i després captureu-les de nou i compareu, perquè l'única evidència que importa és allò que els dispositius han acceptat realment.