Ha senso impilare due livelli di VPN? Tre condizioni da verificare

Prima di aggiungere un secondo livello di crittografia a una VPN, rispondete onestamente a una domanda: che cosa tiene ancora l'osservatore dopo che entrambi i livelli hanno fatto il loro lavoro? Se la risposta è il testo cifrato interno, invariato, allora l'annidamento ha comprato tempo e nient'altro. Quello che segue è una procedura di decisione, non una raccomandazione. Lo stesso schema è CPU sprecata in una distribuzione e la risposta giusta in un'altra, e solo tre condizioni separano le due.

Annotate che cosa conserva l'osservatore

Registrate l'oggetto che un avversario può memorizzare oggi, poi la sequenza di rimozioni che alla fine esporrebbe il testo in chiaro. Un tunnel esterno produce testo cifrato; quando la sua protezione finisce, ciò che resta è il testo cifrato del tunnel interno, ancora sigillato. Rimuovere un involucro non è decifrare. Quella frase descrive l'annidamento, e vale solo finché sopravvive la chiave interna. Nel momento in cui i due livelli condividono qualcosa, la linea temporale collassa in un unico evento.

Dunque l'artefatto utile è una linea temporale, non uno schema a caselle. Per ogni livello, annotate l'estremo, il proprietario della chiave, il controllo dell'identità e l'anno in cui si prevede che l'ipotesi fallisca.

Un modo pratico per verificare la vostra affermazione: supponete che l'osservatore registri tutto e non si arrenda mai. Con questa ipotesi, il progetto protegge ancora il carico utile per la durata richiesta? Se la risposta dipende dal fatto che l'osservatore scelga di non memorizzare il traffico, il progetto non ha risposta.

Condizione prima: i livelli terminano in luoghi diversi?

L'annidamento conviene quando i due livelli terminano in domini di fiducia diversi, per esempio un gateway IPsec gestito dal provider davanti a un tunnel a livello applicativo che termina dentro la vostra rete. Allora rompere il livello esterno produce testo cifrato che solo il vostro host può aprire, e il provider non vede mai testo in chiaro. Mettete entrambi i livelli sullo stesso gateway e quella proprietà svanisce. Chi compromette la scatola legge il traffico tra le due operazioni di decifratura, per quanti involucri mostri lo schema.

Verificatelo con lo stato installato, non con il progetto. Su Linux, ip xfrm state elenca ogni associazione di sicurezza e i suoi estremi, il che stabilisce dove ogni livello si ferma davvero.

Condizione seconda: il materiale delle chiavi è davvero indipendente?

Due livelli costruiti da un solo certificato, una sola chiave precondivisa o una sola libreria del fornitore sono un unico livello con passaggi extra. Allora una sola credenziale compromessa apre entrambi, e un solo bug di implementazione li rimuove entrambi in una volta. L'indipendenza deve essere visibile nella configurazione, non affermata su una diapositiva.

Qui la derivazione ibrida delle chiavi supera l'impilamento dei tunnel. IKEv2 può trasportare più scambi di chiavi in una sola negoziazione, così un gruppo classico e un KEM post-quantistico possono entrambi alimentare le stesse chiavi di sessione invece di essere avvolti l'uno attorno all'altro. Il risultato è una sola associazione di sicurezza le cui chiavi dipendono da entrambi i segreti, e un attaccante deve romperli entrambi. È una costruzione documentata con una composizione definita, cosa che un impilamento fatto in casa di due prodotti VPN non è. Su strongSwan, swanctl --list-sas stampa la proposta negoziata per ogni SA, ed è così che confermate che cosa ha girato davvero e non che cosa avete configurato.

Condizione terza: i dati sopravvivono all'ipotesi esterna?

Un livello che deve durare vent'anni ha bisogno di un argomento di vent'anni. Registrare ora e decifrare dopo costa poco, ed è il motivo per cui un livello esterno classico non può essere trattato come un involucro temporaneo attorno a qualcosa di più forte.

Chiedete quando ogni chiave diventa recuperabile, non se il cifrario è rotto oggi. Uno scambio di chiavi statico senza segretezza in avanti fallisce retroattivamente il giorno in cui cade la chiave privata. L'accordo di chiavi effimero fallisce solo per le sessioni che un avversario può attaccare mentre sono attive, o quando l'algoritmo stesso si indebolisce. Questa differenza decide se un livello interno aiuta ancora nel 2040. Decide anche se il livello esterno cambia qualcosa, perché un livello esterno con la vita della chiave più debole diventa semplicemente il punto più precoce della linea temporale.

Che cosa costruire invece quando la risposta è no

Se una delle tre condizioni fallisce, abbandonate l'annidamento e spendete lo sforzo sul livello che porta davvero il requisito di durata. Configurate uno scambio di chiavi ibrido nel protocollo che già eseguite, mantenete l'implementazione aggiornata e annotate la composizione su cui contate. Nominare ML-KEM in un documento di progetto non è una proprietà di sicurezza, e FIPS 203 definisce il meccanismo di incapsulamento delle chiavi, non il vostro tunnel.

Dove un secondo livello si guadagna davvero il suo posto, descrivetelo come difesa in profondità e non come prova. Poi verificate la composizione: quale estremo detiene quale chiave, quale identità controlla ciascun lato e che cosa può leggere un operatore con accesso alla console. Un progetto che sopravvive a queste tre domande vale la CPU extra. Uno che non lo fa è solo uno schema.

Prima della finestra di cambiamento, catturate la tabella SA attuale e le proposte negoziate, poi catturatele di nuovo e confrontatele, perché l'unica prova che conta è ciò che i dispositivi hanno davvero accettato.