Convén apilar dúas capas de VPN? Tres condicións para comprobar

Antes de engadir unha segunda capa de cifrado a unha VPN, responda con honestidade unha pregunta: que conserva aínda o observador despois de que ambas as capas fixesen o seu traballo? Se a resposta é o texto cifrado interno, sen cambios, entón o aniñamento comprou tempo e nada máis. O que segue é un procedemento de decisión, non unha recomendación. O mesmo diagrama é CPU desperdiciada nunha implantación e a resposta correcta noutra, e só tres condicións separan ambas as dúas.

Anote que conserva o observador

Rexistre o obxecto que un adversario pode almacenar hoxe e despois a secuencia de retiradas que acabaría expoñendo o texto claro. Un túnel exterior produce texto cifrado; cando remata a súa protección, o que queda é o texto cifrado do túnel interior, aínda selado. Retirar unha envoltura non é descifrar. Esa frase describe o aniñamento, e só é certa mentres a chave interna sobrevive. No momento en que as dúas capas comparten algo, a liña temporal colápsase nun único suceso.

Así que o artefacto útil é unha liña temporal, non un diagrama de caixas. Para cada capa, anote o extremo, o propietario da chave, a comprobación de identidade e o ano no que se espera que falle a suposición.

Unha forma práctica de probar a súa propia afirmación: supoña que o observador o rexistra todo e nunca se rende. Baixo esa suposición, o deseño segue protexendo a carga útil durante a súa vida útil requirida? Se a resposta depende de que o observador elixa non almacenar tráfico, o deseño non ten resposta.

Condición primeira: rematan as capas en lugares distintos?

O aniñamento compensa cando as dúas capas rematan en dominios de confianza distintos, por exemplo unha pasarela IPsec xestionada polo provedor diante dun túnel de nivel de aplicación que remata dentro da súa propia rede. Entón, romper a capa exterior produce texto cifrado que só o seu host pode abrir, e o provedor nunca ve texto claro. Poña ambas as capas na mesma pasarela e esa propiedade desaparece. Quen compromete a caixa le o tráfico entre as dúas operacións de descifrado, por moitas envolturas que mostre o diagrama.

Compróbeo co estado instalado e non co deseño. En Linux, ip xfrm state lista cada asociación de seguridade e os seus extremos, o que determina onde se detén realmente cada capa.

Condición segunda: é realmente independente o material de chaves?

Dúas capas construídas cun só certificado, unha soa chave precompartida ou unha soa biblioteca de provedor son unha capa con pasos extra. Entón unha soa credencial comprometida abre ambas as dúas, e un só erro de implementación elimina ambas ao mesmo tempo. A independencia debe ser visible na configuración, non afirmada nunha diapositiva.

Aquí o establecemento híbrido de chaves supera o apilamento de túneles. IKEv2 pode transportar varios intercambios de chaves nunha soa negociación, de xeito que un grupo clásico e un KEM poscuántico poden alimentar as mesmas chaves de sesión en lugar de envolverse un a outro. O resultado é unha soa asociación de seguridade cuxas chaves dependen de ambos os segredos, e o atacante ten que romper os dous. Trátase dunha construción documentada cunha composición definida, cousa que non é un apilado caseiro de dous produtos VPN. En strongSwan, swanctl --list-sas imprime a proposta negociada para cada SA, e así confirma que se executou e non que configurou.

Condición terceira: sobreviven os datos á suposición exterior?

Unha capa que debe durar vinte anos necesita un argumento de vinte anos. Rexistrar agora e descifrar despois é barato, e por iso unha capa exterior clásica non se pode tratar como unha envoltura temporal arredor de algo máis forte.

Pregunte cando se volve recuperable cada chave, non se o cifrado está roto hoxe. Un intercambio de chaves estático sen segredo cara a adiante falla retroactivamente o día en que cae a chave privada. O acordo de chaves efémero falla só nas sesións que un adversario pode atacar mentres están vivas, ou cando o propio algoritmo se debilita. Esa diferenza decide se unha capa interior aínda axuda en 2040. Tamén decide se a capa exterior cambia algo, porque unha capa exterior coa vida de chave máis débil simplemente se converte no punto máis temperán da liña temporal.

Que construír no seu lugar cando a resposta é non

Se falla calquera das tres condicións, abandone o aniñamento e gaste o esforzo na capa que realmente soporta o requisito de vida útil. Configure un intercambio híbrido de chaves no protocolo que xa executa, manteña a implementación ao día e anote a composición na que confía. Nomear ML-KEM nun documento de deseño non é unha propiedade de seguridade, e FIPS 203 define o mecanismo de encapsulación de chaves, non o seu túnel.

Onde unha segunda capa se gaña de verdade o seu lugar, descríbaa como defensa en profundidade e non como proba. Despois verifique a composición: que extremo garda que chave, que identidade comproba cada lado e que pode ler un operador con acceso á consola. Un deseño que sobrevive a esas tres preguntas merece a CPU extra. Un que non o fai é un diagrama.

Antes da xanela de cambio, capture a táboa SA actual e as propostas negociadas, e despois capturenas de novo e compare, porque a única evidencia que importa é aquilo que os dispositivos aceptaron realmente.