Segretezza in avanti per una VPN: cosa può aprire una chiave rubata

Registrate oggi un tunnel cifrato, rubate l'anno prossimo la chiave privata a lungo termine del server e provate a decifrare la registrazione. La segretezza in avanti è la proprietà che dice che la chiave rubata non basterà da sola. È un'affermazione su sessioni registrate e segreti specifici, non una promessa generale che il tunnel fosse sicuro. Delimitare bene l'ambito è ciò che rende utile il termine.

La domanda riguarda una registrazione, non la sessione attiva

La chiave a lungo termine identifica l'estremità e firma lo handshake. Le chiavi di sessione cifrano il traffico reale e, in un progetto a segretezza in avanti, derivano da materiale fresco di scambio chiavi che entrambe le parti generano e poi scartano. Un attaccante che possiede solo la chiave a lungo termine non può ricostruire quei valori scartati. Un attaccante che possiede lo stato di sessione attivo può ancora, ed è per questo che la garanzia riguarda il passato e non il presente.

L'affermazione è condizionale: vale solo se i segreti effimeri sono stati davvero distrutti e il protocollo è quello che pensate. Un dispiegamento misto può soddisfarla su un tunnel e fallire su un altro.

Un segreto non deve ricostruire gli altri

Controllate la modalità negoziata invece della pagina di marketing. L'output dello handshake nomina lo scambio chiavi e la versione del protocollo.

openssl s_client -connect vpn.example.com:443 -tls1_3 -brief
swanctl --list-sas

Il riepilogo di s_client mostra la versione di TLS e il gruppo di scambio chiavi, e un gruppo effimero è il segno visibile di un accordo di chiavi a segretezza in avanti. L'elenco di swanctl mostra le associazioni IKE e CHILD con i loro timer di rinnovo delle chiavi, così potete vedere se il dispiegamento rinnova le chiavi secondo un calendario. Uno scambio di chiavi RSA statico, o una vecchia modalità di compatibilità, perde la proprietà qualunque sia il nome della cifratura. Annotate la modalità che avete osservato, non quella che il fornitore pubblicizzava.

Rinnovare le chiavi non è automaticamente segretezza in avanti

Con quale frequenza un tunnel rinnovi le chiavi è una questione separata da come ogni chiave viene derivata. Un progetto che rigenera le chiavi da un segreto a lungo termine può rinnovarle ogni minuto e comunque fallire la prova, perché una compromissione successiva le ricostruisce tutte. Al contrario, un protocollo con rinnovo poco frequente può restare a segretezza in avanti quando ogni scambio è indipendente. Leggete la derivazione, non l'intervallo, e non confondete un timer di riconnessione breve con una garanzia crittografica.

La stessa confusione compare con i nomi delle cifrature: una cifratura moderna non dice nulla su come sia arrivata la sua chiave.

Cosa resta visibile dopo la garanzia

La segretezza in avanti protegge il testo in chiaro delle sessioni registrate da una futura compromissione delle chiavi, e non fa nulla contro un attaccante che legge il traffico attivo su un'estremità compromessa. Non rimuove dalla registrazione gli indirizzi di destinazione, il momento né il volume, e non limita quanto a lungo un operatore conserva i registri delle connessioni. Non rende nemmeno affidabile un client compromesso, perché l'attaccante siede già dove il contenuto esiste in chiaro.

Quando un fornitore sostiene la segretezza in avanti, chiedete quale segreto a lungo termine si presume rubato e quali segreti di sessione restano indisponibili. Se queste due domande hanno risposte nette, l'affermazione significa qualcosa.