Vale a pena empilhar duas camadas de VPN? Três condições a verificar

Antes de adicionar uma segunda camada de criptografia a uma VPN, responda com honestidade a uma pergunta: o que o observador ainda detém depois que as duas camadas fizeram o seu trabalho? Se a resposta for o texto cifrado interno, sem alterações, então o aninhamento comprou tempo e nada mais. O que se segue é um procedimento de decisão, não uma recomendação. O mesmo diagrama é CPU desperdiçada numa implantação e a resposta correta noutra, e apenas três condições separam as duas.

Anote o que o observador conserva

Registe o objeto que um adversário pode armazenar hoje e, em seguida, a sequência de remoções que acabaria por expor o texto em claro. Um túnel exterior produz texto cifrado; quando a sua proteção termina, o que resta é o texto cifrado do túnel interior, ainda selado. Remover um invólucro não é decifrar. Essa frase descreve o aninhamento, e só é verdadeira enquanto a chave interna sobreviver. No momento em que as duas camadas partilham algo, a linha temporal colapsa num único evento.

Assim, o artefacto útil é uma linha temporal, não um diagrama de caixas. Para cada camada, anote o extremo, o dono da chave, a verificação de identidade e o ano em que se espera que a suposição falhe.

Uma forma prática de testar a sua própria afirmação: suponha que o observador registe tudo e nunca desista. Sob essa suposição, o desenho ainda protege a carga útil durante a vida útil exigida? Se a resposta depender de o observador escolher não armazenar tráfego, o desenho não tem resposta.

Condição um: as camadas terminam em locais diferentes?

O aninhamento compensa quando as duas camadas terminam em domínios de confiança diferentes, por exemplo uma passagem IPsec gerida pelo fornecedor à frente de um túnel ao nível da aplicação que termina dentro da sua própria rede. Então, quebrar a camada exterior produz texto cifrado que só o seu host pode abrir, e o fornecedor nunca vê texto em claro. Coloque as duas camadas na mesma passagem e essa propriedade desaparece. Quem compromete a caixa lê o tráfego entre as duas operações de decifragem, por muitos invólucros que o diagrama mostre.

Verifique isso com o estado instalado e não com o desenho. No Linux, ip xfrm state lista cada associação de segurança e os seus extremos, o que determina onde cada camada realmente pára.

Condição dois: o material das chaves é realmente independente?

Duas camadas construídas a partir de um único certificado, de uma única chave pré-partilhada ou de uma única biblioteca de fornecedor são uma camada com passos extra. Então uma única credencial comprometida abre ambas, e um único erro de implementação remove ambas de uma vez. A independência tem de ser visível na configuração, não afirmada num slide.

É aqui que o estabelecimento híbrido de chaves supera o empilhamento de túneis. O IKEv2 pode transportar várias trocas de chaves numa só negociação, pelo que um grupo clássico e um KEM pós-quântico podem ambos alimentar as mesmas chaves de sessão em vez de serem enrolados um no outro. O resultado é uma única associação de segurança cujas chaves dependem dos dois segredos, e o atacante tem de quebrar ambos. Trata-se de uma construção documentada com uma composição definida, o que um empilhamento caseiro de dois produtos VPN não é. No strongSwan, swanctl --list-sas imprime a proposta negociada para cada SA, e é assim que confirma o que realmente correu e não o que configurou.

Condição três: os dados sobrevivem à suposição exterior?

Uma camada que tem de durar vinte anos precisa de um argumento de vinte anos. Registar agora e decifrar mais tarde é barato, e é por isso que uma camada exterior clássica não pode ser tratada como um invólucro temporário em torno de algo mais forte.

Pergunte quando cada chave se torna recuperável, não se a cifra está quebrada hoje. Uma troca de chaves estática sem sigilo futuro falha retroativamente no dia em que a chave privada cai. O acordo de chaves efémero falha apenas nas sessões que um adversário pode atacar enquanto estão vivas, ou quando o próprio algoritmo enfraquece. Essa diferença decide se uma camada interior ainda ajuda em 2040. Também decide se a camada exterior muda alguma coisa, porque uma camada exterior com a vida de chave mais fraca torna-se simplesmente o ponto mais precoce da linha temporal.

O que construir em vez disso quando a resposta é não

Se qualquer das três condições falhar, abandone o aninhamento e gaste o esforço na camada que realmente suporta o requisito de vida útil. Configure uma troca híbrida de chaves no protocolo que já executa, mantenha a implementação atualizada e anote a composição em que confia. Nomear ML-KEM num documento de desenho não é uma propriedade de segurança, e FIPS 203 define o mecanismo de encapsulamento de chaves, não o seu túnel.

Onde uma segunda camada realmente merece o seu lugar, descreva-a como defesa em profundidade e não como prova. Depois verifique a composição: que extremo guarda que chave, que identidade cada lado verifica e o que um operador com acesso à consola pode ler. Um desenho que sobrevive a essas três perguntas vale a CPU extra. Um que não sobrevive é apenas um diagrama.

Antes da janela de alteração, capture a tabela SA atual e as propostas negociadas, e depois capture-as de novo e compare, porque a única evidência que importa é aquilo com que os dispositivos concordaram realmente.