Perfect Forward Secrecy nel VPN spiegato semplice: come PFS protegge i dati anche dopo un attacco

Perché Perfect Forward Secrecy è diventato imprescindibile per le VPN nel 2026

I dati valgono più dell'oro

Nel 2026 la crittografia su Internet non è più un lusso, ma una questione di sopravvivenza per le aziende. Trasferiamo tramite VPN tutto: contabilità, codice sorgente, database clienti, accessi ai sistemi interni. E questo interessa non solo gli hacker, ma anche la concorrenza spionistica, attori malevoli interni e, purtroppo, a volte anche provider troppo curiosi. La cattiva notizia: intercettare il traffico è diventato più facile. Dispositivi TAP di rete a basso costo, storage cloud accessibile per conservare terabyte di dati a lungo, indici dei metadati: tutto ciò consente a qualcuno di accumulare silenziosamente dati cifrati per anni, per poi tentare di decifrarli quando ne avrà l’occasione.

La buona notizia: Perfect Forward Secrecy (PFS) spezza questa cattiva abitudine. Anche se qualcuno dovesse rubare la chiave a lungo termine del server o riuscire in un phishing su un admin, PFS non permette di decifrare le vecchie connessioni. Ogni sessione VPN vive una sua vita crittografica a sé, e dopo la sua fine è come una traccia di carta che hai bruciato. Tutto quello che è stato intercettato resta un insieme di byte inutilizzabili.

Cosa offre esattamente PFS

PFS garantisce la segretezza diretta: la compromissione delle chiavi a lungo termine non rivela le chiavi delle sessioni passate. Ogni sessione riceve un segreto effimero e fresco, calcolato durante uno scambio sicuro (di solito con lo schema Diffie-Hellman su curve ellittiche – ECDHE). Queste chiavi non si ripetono, non vengono archiviate e scompaiono appena non servono più. Da qui la magia: senza chiave non c’è nulla da decriptare.

Un altro vantaggio è la resilienza condizionale alle minacce future. Immagina un avversario che registra il tuo traffico oggi con l’intento di decifrarlo tra cinque anni quando avrà potenza computazionale sufficiente. Con PFS deve agire in tempo reale durante la sessione. Se perde quella finestra, addio, niente secondi tentativi. Questo ha un valore enorme nel contesto della tattica "harvest-now-decrypt-later".

Chi ne ha davvero bisogno

La risposta è semplice: chiunque non voglia che il passato lo raggiunga nel futuro. Banche, fintech e assicurazioni – ovviamente. Aziende IT, approccio DevOps, accesso a Git e artefatti – naturalmente. Organizzazioni mediche con dati personali, avvocati con corrispondenza riservata, provider di servizi cloud, media e persino freelance che si connettono a VPN clienti da varie reti. Spesso sentiamo: "Siamo piccoli, chi dovrebbe interessarsi a noi?". Ma gli attacchi sono massivi, economici e automatizzati. Quando si parla di crittografia, la dimensione dell’azienda non è più un argomento.

E sì, è importante anche al di fuori del B2B. VPN domestiche per privacy e streaming, router con client integrati, perfino app per smartphone – se il protocollo supporta PFS, il tuo passato resta nel passato.

Cripto-base: chiavi e sessioni nelle VPN

Chiavi di sessione vs chiavi a lungo termine

Le chiavi a lungo termine sono il tuo "passaporto": confermano che sei davvero tu. Il server VPN ha un certificato e una chiave privata, il client ha le sue credenziali, a volte anche un certificato. Queste chiavi vivono a lungo e si cambiano raramente. Le chiavi di sessione sono biglietti usa e getta: generate per ogni connessione, durano minuti o ore e spariscono senza lasciare traccia.

Nei protocolli tradizionali senza PFS, chiunque ottenga la chiave privata del server può decriptare tutto il traffico registrato: una chiave vale per migliaia di sessioni. PFS rompe questa dipendenza: la chiave a lungo termine serve solo a negoziare un nuovo segreto di sessione, ma non consente di risalire a retroattivamente a esso.

Crittografia simmetrica e asimmetrica

VPN e TLS utilizzano quasi sempre entrambi i mondi in coppia. La crittografia asimmetrica (coppie di chiavi, certificati) serve ad autenticare le parti e a scambiare in modo sicuro i segreti. La crittografia simmetrica (una chiave comune) è usata per cifrare velocemente i dati dopo la stretta di mano. È un compromesso tra velocità e sicurezza: l’asimmetrico è più lento ma fondamentale per iniziare, il simmetrico è veloce e mantiene il flusso.

PFS si applica proprio nella fase di scambio delle chiavi. Si negozia un segreto condiviso temporaneo senza rivelarlo in chiaro, e da questo si derivano le chiavi per la crittografia simmetrica (AES-GCM, ChaCha20-Poly1305). Poi si può iniziare a scambiare traffico in sicurezza.

Dove risiedono le chiavi nella pratica

Le chiavi a lungo termine del server sono tipicamente conservate in depositi sicuri, a volte in moduli hardware (HSM). Le chiavi di sessione vivono nella memoria dei processi, per poco e in modo operativo. Nelle VPN moderne è buona norma minimizzare i log degli handshake, pulire la memoria, limitare i privilegi di accesso e usare implementazioni cifrate sicure.

È importante capire che la sicurezza non si basa solo sulla matematica. Serve disciplina operativa: permessi corretti, aggiornamenti, controllo delle librerie, disabilitazione degli algoritmi deboli. PFS non salva se la chiave privata giace sul desktop in un file key.pem. Ma come parte di una configurazione corretta è uno scudo potente.

Come funziona Perfect Forward Secrecy a grandi linee

Definizione e concetto chiave

PFS è una proprietà dei protocolli per cui la compromissione delle chiavi a lungo termine non rivela i segreti delle sessioni passate. Si ottiene usando chiavi effimere (usa e getta) per ogni handshake. Il punto essenziale è l’assenza di una relazione crittografica tra l’identità a lungo termine e il segreto specifico di sessione. La connessione esiste solo durante lo scambio e solo in una direzione.

In altre parole, anche se qualcuno dovesse rubare la tua chiave privata domani, le conversazioni di ieri rimarranno segrete. Non esiste un pulsante magico "decripta il passato". La chiave di sessione non viene memorizzata, ed è impossibile calcolarla da tracce pubbliche di scambio, se i parametri e la curva sono impostati correttamente.

Chiavi effimere: nate e sparite velocemente

Le chiavi effimere sono coppie temporanee create per uno scambio specifico. Il client genera una chiave privata effimera, anche il server ne crea una. Scambiano le parti pubbliche e calcolano un segreto condiviso che nessuno all’esterno può vedere. Da questo derivano le chiavi per la cifratura simmetrica tramite funzioni HKDF. Finito lo scambio, le chiavi vengono eliminate e dimenticate. Bellissimo.

La conclusione importante: il valore del traffico intercettato con PFS si svaluta più in fretta di uno yogurt senza frigorifero. Vuoi decriptare? Devi agire proprio ora, mentre l’handshake è vivo e la sessione attiva. Se non ce la fai, il treno è partito.

Rompere l’eredità: come PFS "taglia" il passato

Nei protocolli senza PFS le chiavi di sessione monouso derivano dal segreto a lungo termine. Ottieni la chiave principale e puoi accedere a tutte le conversazioni passate. Con PFS questo non succede. L’unico legame tra dati a lungo termine e sessione è nella verifica e negoziazione dei parametri, ma il segreto è prodotto da chiavi effimere indipendenti dal certificato server e dalle credenziali client.

È come avere un telefono usa e getta per ogni chiamata: parli venti minuti e poi lo butti nel cestino. Anche se qualcuno ruba il numero dalla rubrica, le chiamate sul telefono buttato non hanno alcun valore.

Lo scambio di chiavi Diffie-Hellman ed ECDHE nei dettagli

Diffie-Hellman classico: passo dopo passo

L’essenza di DH è semplice e geniale. Le parti concordano parametri pubblici di gruppo: grandi numeri e modulo (nella versione classica) o una curva (per ECDH). Il client sceglie un numero segreto a, il server b. Il client invia g^a mod p, il server g^b mod p. Ognuno calcola il segreto condiviso g^(ab) mod p usando il suo segreto privato e la parte pubblica dell’altro. Un osservatore che vede solo g^a e g^b senza conoscere a o b non può ricavare il segreto.

Per aumentare la sicurezza si usano gruppi standard con resistenza provata e non si riutilizzano valori efimeri. Il cuore è il problema del logaritmo discreto: i metodi noti non permettono di estrarre il segreto in tempo reale se i parametri sono corretti.

ECDHE: curve ellittiche per velocità e affidabilità

In ECDHE si usa l’aritmetica dei punti su curve ellittiche invece dell’aritmetica modulare. I vantaggi sono chiavi più piccole per la stessa sicurezza e velocità elevata, particolarmente su dispositivi mobili e embedded. Nel 2026 lo standard de facto è Curve25519 (X25519) per ECDH: veloce, robusta, con implementazioni curate.

Lo schema è simile: le parti si scambiano punti pubblici, ognuna moltiplica il punto dell’altra per il proprio scalare privato e ottiene un segreto condiviso, da cui con HKDF si ricavano le chiavi. L’importante è la 'E' in ECDHE, che indica effimero – chiavi usa e getta. Questa è la realizzazione pratica di PFS nell’handshake.

Perché intercettare non aiuta gli attaccanti

Un attacco passivo vede solo componenti pubblici e traffico cifrato. Per recuperare il segreto servirebbe risolvere un problema matematico difficile (logaritmo discreto nel gruppo o curva), senza soluzioni pratiche con parametri adeguati. La compromissione della chiave a lungo termine non aiuta: quella chiave non contiene segreti effimeri, serve solo per firmare o autenticare lo scambio.

Gli attacchi attivi (come man-in-the-middle) si scontrano con l’autenticazione: certificati, pre-shared key con autenticazione, meccanismi come tls-auth o tls-crypt in OpenVPN. Se non si può sostituire la fiducia, infilarsi senza lasciare tracce è impossibile. Se la fiducia è solida, l’archivio intercettato è inutile.

Perché non si può decifrare dopo il traffico intercettato

Modello di minaccia harvest-now-decrypt-later

È uno scenario reale: l’avversario registra le sessioni cifrate per anni sperando un giorno di ottenere la chiave privata o un computer quantistico per tornare all’archivio. Senza PFS funziona spaventosamente bene. Con PFS quasi per niente, perché le chiavi di sessione passate non si recuperano da fughe future.

Vediamo grandi attori limitare i rischi: sessioni brevi, parametri rigidi per ECDHE, blocco di cifrari e protocolli obsoleti. L’idea è tagliare il passato dai problemi futuri. Può sembrare noioso, ma è una difesa strategica.

Cosa si perde senza PFS

Senza PFS, la compromissione del server rivela tutto ciò che ha mai cifrato. È come la chiave di tutta la casa conservata in un solo posto: se la perdi, non solo la cassaforte si apre, ma anche tutte le stanze. In più, si è tentati di tener vive le sessioni a lungo per risparmiare CPU, il che peggiora la situazione: più a lungo è valida una chiave, più valore ha per gli attaccanti.

Anche se oggi sembra tutto sotto controllo, domani potresti aggiornare una libreria, emergere una vulnerabilità o qualcuno caricare un dump di memoria in un ticket – e il traffico passato sarà a rischio. PFS trasforma queste situazioni da disastri a problemi contenuti.

Con PFS la compromissione non ricalca la storia

Immagina che venga rubata la chiave privata del server. Un problema serio. Ma l’archivio delle comunicazioni cifrate dell’anno passato resta al sicuro. L’attaccante deve aspettare nuove connessioni e agire in tempo reale, solo se può interferire nella catena di fiducia. Questo aumenta molto la difficoltà dell’attacco e abbassa i rischi.

D’altro canto, PFS non sostituisce le regole base: rotazione dei certificati, politiche rigorose sui diritti d’accesso, log puliti senza segreti, protezione degli endpoint. È un gioco di squadra, e PFS è un attaccante potente nella tua difesa crittografica.

Quali protocolli VPN supportano PFS nel 2026

TLS 1.3: PFS di default

In TLS 1.3 PFS non è un’opzione, è lo standard. Tutto l’handshake si basa su (EC)DHE. Non ci sono scambi di chiavi RSA obsoleti. Nel contesto VPN è fondamentale per OpenVPN (modalità TLS) e per servizi su HTTPS (DoH, HTTP/3). In più: crittografia semplificata, handshake più veloci e migliore performance.

Nel 2026 la maggioranza di client e server usa TLS 1.3. Questo garantisce PFS automaticamente, se non si attivano impostazioni antiche per compatibilità. Regola semplice: TLS moderno, curve moderne = segretezza diretta.

OpenVPN: ECDHE e tls-crypt come colonna portante

OpenVPN supporta da tempo PFS tramite DHE/ECDHE. Parametri consigliati: tls-version-min 1.2 (meglio 1.3 dove possibile), ECDHE con X25519 o secp256r1, cifrari AES-256-GCM o ChaCha20-Poly1305, e tls-crypt abilitato per proteggere il canale di controllo. Questo setup offre non solo PFS ma anche protezione metadata degli handshake da occhi indiscreti.

Nel 2026 molti amministratori scelgono X25519 per velocità e semplicità, impostano reneg-sec tra 3 e 5 minuti per rinnovare regolarmente le chiavi e usano verify-x509-name per una verifica rigorosa del server. Economico, solido e affidabile.

WireGuard: PFS integrato nel protocollo

WireGuard si basa sul protocollo Noise IK e usa ECDH su Curve25519 (X25519) con rekey regolari. Chiavi effimere e sessioni brevi sono nel DNA del protocollo. Le chiavi si ricalcolano generalmente ogni 120 secondi di attività o al raggiungimento di un certo volume di dati. PFS non è un’opzione ma una norma essenziale.

Nel 2026 WireGuard è ovunque: nei kernel Linux, router, sistemi mobili, persino nelle infrastrutture SASE/ZTNA. Offre ottime performance su mobile, recupero stabile della sessione in roaming e crittografia trasparente senza opzioni complesse che si potrebbero rompere accidentalmente.

IKEv2/IPsec: classico potente con PFS in Phase 2

In IKEv2 PFS si attiva nella fase CHILD_SA (seconda fase). Si esprime configurando una richiesta di DH aggiuntivo per ogni Security Association (SA). Si scelgono gruppi moderni: ECP (es. ECP256) o ffdhe3072 e superiori, e si usa rekey ogni 30-60 minuti di traffico attivo.

Buone notizie: implementazioni moderne come strongSwan, libreswan e gateway commerciali nel 2026 raccomandano PFS e gruppi forti di default. Male: in alcune reti si trovano ancora profili legacy senza PFS, da migrare prioritariamente.

Prestazioni e overhead: fa paura attivare PFS?

Dati pratici: overhead negli handshake

Mito: «PFS rallenta tanto». Realtà: su CPU moderne e algoritmi giusti l’incremento nell’handshake è di poche decine di millisecondi. In sessioni VPN prolungate si nota poco rispetto al traffico e alla latenza di rete. Inoltre TLS 1.3 ha ottimizzato la stretta di mano, WireGuard riduce la complessità del protocollo.

Misurazioni 2025-2026 su VM cloud con AES-NI e ECDHE X25519 mostrano un overhead handshake dell’1-3% del tempo totale per stabilire il canale. Su ARM mobile con ChaCha20-Poly1305 è simile: carico aggiuntivo trascurabile, ma sicurezza molto maggiore.

Scelta dei cifrari in base all’hardware

Se i server sono x86 con AES-NI, AES-128/256-GCM vola. Su ARM e ambienti mobili ChaCha20-Poly1305 spesso supera AES. Fondamentale: non mischiare cifrature obsolete per «compatibilità». Nel 2026 possiamo vivere tranquilli con ECDHE X25519 + AES-GCM o ChaCha20-Poly1305.

Ulteriore boost arriva da configurazioni MTU corrette, gestione accurata delle code e disattivazione di opzioni obsolete che aggiungono overhead inutile. E ovviamente tenete aggiornate le librerie crittografiche: OpenSSL, BoringSSL, wolfSSL includono ottimizzazioni che valgono più di ogni altra cosa.

Rekey ottimale e timer

Frequenza cambio chiavi: compromesso necessario. Troppo raro = rischio maggiore. Troppo frequente = consumo CPU per handshake. Valori sensati: 2-5 minuti in scenari alla WireGuard, 30-60 minuti per CHILD_SA IPsec con tunnel stabili, 3-10 minuti reneg in OpenVPN. Se traffico elevato e costante, scegli un valore medio e monitora le metriche.

Indicatore chiave: latenza p95/p99 nel setup del flusso dopo rekey. Se picchi sono minimi, gli utenti non se ne accorgeranno. E riduci notevolmente il rischio delle «chiavi lunghe».

Pratica: come attivare e verificare PFS

Controllo rapido di TLS e HTTPS

Anche se parliamo di VPN, è utile saper verificare PFS su HTTPS, perché i meccanismi sono uguali. Controlla il key exchange: ECDHE o DHE va bene, RSA key exchange no. Strumenti diagnostici moderni mostrano la curva usata (X25519, secp256r1) e il cifrario (AES-GCM, ChaCha20). Vedi X25519 e TLS 1.3? Hai PFS "in scatola".

Per diagnostica interna, controlla i log server, abilita output dettagliato in ambiente di test e assicurati che si usino chiavi effimere, non negoziazioni statiche. Semplice: c’è ECDHE, c’è PFS.

OpenVPN: cosa verificare nel config

Cerca tls-version-min 1.2 o 1.3, imposta tls-cipher o ncp-ciphers con ECDHE, attiva tls-crypt o tls-auth, configura reneg-sec a un valore ragionevole. Genera parametri DH sul server, ma per velocità e sicurezza usa ECDHE con X25519. Assicurati che sul client remote-cert-tls server sia attivo e verify-x509-name controlli il nome del server. Così eviti MiTM e garantisci che PFS funzioni correttamente.

Controlla i log: all’handshake devono apparire ECDHE e cifrari AEAD moderni. Se trovi riferimenti a chiavi statiche senza scambi effimeri, qualcosa non va.

WireGuard: controlla rekey e curva

WireGuard integra PFS via Noise. Usando build standard, hai già ECDH X25519 e cambio regolare chiavi. Controlla la frequenza di rekey: di default attorno a 120 secondi di attività. Assicurati che non ci sia un logging eccessivo del materiale chiave — non deve esserci.

Per la validazione, abilita il debug su nodo di test e osserva installazioni di sessioni, volumi dati e tempi di riconnessione al cambio rete. Se è stabile, PFS funziona come previsto.

IKEv2/IPsec: PFS in CHILD_SA

Verifica che il profilo richieda un DH aggiuntivo per la creazione di CHILD_SA. Scegli gruppi moderni: ECP256 o superiori, ffdhe3072 o ffdhe4096. Imposta rekey tra 30 e 60 minuti, e più frequentemente se ci sono dati sensibili. Assicurati che gruppi obsoleti come modp1024 siano disabilitati ovunque.

Controlla i log del gateway: devono comparire righe con il gruppo DH per PFS durante la creazione di CHILD_SA. Se mancano, CHILD_SA è senza forward secrecy: cambia subito la politica.

Migliori pratiche per parametri e crittopolitiche nel 2026

Curve e gruppi

Raccomandazione per il 2026: X25519 come curva principale per ECDHE e ECDH. Alternative accettabili: secp256r1 per compatibilità con HSM aziendali e alcuni dispositivi di rete. Per DH classico almeno ffdhe2048, meglio ffdhe3072. Ma se puoi, vai su X25519: più semplice e veloce.

Evita curve con storia dubbia e gruppi troppo vecchi. Lista nera: secp192r1, modp1024, curve esotiche non ampiamente verificate. Curve popolari e diffuse hanno implementazioni più affidabili e meno bug.

Cifrari e modalità

Comandano i modi AEAD: AES-128/256-GCM e ChaCha20-Poly1305. Non ha senso trascinare CBC, RC4 e vecchie reliquie. Su x86 con AES-NI usa AES-GCM, su ARM e ambienti misti ChaCha20-Poly1305 è spesso preferibile. Idee chiave: poche opzioni, meno confusione, meno rischi di errori.

HKDF basato su SHA-256 è lo standard per derivare chiavi dal segreto condiviso. Evita dipendenze obsolete su SHA-1. Non complicare i parametri solo per estetica: la sicurezza non migliora.

Rotazione chiavi e controllo della superficie d’attacco

Pianifica rotazione dei certificati server ogni 12-18 mesi, meglio se automatizzata. Per le sessioni imposta intervalli rekey ragionevoli (minuti, non ore), vieta tunnel "eterni". Registra pochi log, senza segreti, taglia campi sensibili. Meno conservi, meno devi proteggere e pulire.

E aggiornamenti: anche nel 2026 vulnerabilità importanti capitano ancora. Un patch tempestivo per le librerie crittografiche costa meno di qualsiasi analisi forense e sicuramente meno di problemi di reputazione.

PFS e crittografia post-quantistica: uno sguardo a 5 anni

Rischio quantistico: niente panico, ma pianificazione

I computer quantistici non rompono ancora ECDH e RSA nel mondo reale, ma la moda "raccogli ora, decifra dopo" rende la questione urgente. PFS oggi limita il valore degli archivi intercettati. Per decriptare vecchie sessioni l’attaccante deve aver agito all’istante, non domani con il "quantum sword".

Non esonera dalla migrazione a schemi post-quantistici, ma guadagni tempo. In pratica: attiva PFS, aggiorna protocolli, segui l’introduzione di scambi chiave ibridi.

Scambi ibridi: X25519 più KEM post-quantistico

Nel 2026 si parla molto di handshake ibridi: ECDHE classico (X25519) più KEM post-quantistico (famiglie ML-KEM, prima note come Kyber). L’idea è resistere sia ad attacchi classici che quantistici durante la transizione. Se una parte si rompe, l’altra resta solida.

Per il mondo VPN è un tema in evoluzione: implementazioni pilota per TLS, esperimenti su IKEv2, discussioni su estensioni WireGuard. Se progetti prodotti a lunga vita, prepara l’upgrade dello stack, ma non comprometter la sicurezza attuale per scenari ipotetici – PFS già chiude la falla principale della decrittazione retroattiva.

Roadmap di implementazione

Piano realistico: oggi usa ECDHE con PFS e cifrari moderni, aggiorna regolarmente le librerie, monitora il supporto per handshake ibridi sulle tue piattaforme. Quando gli standard si stabilizzano e il supporto diventa comune, pianifica rollout a tappe: ambienti di test, canary deployment, migrazione graduale client.

Nota importante: algoritmi post-quantistici aumentano la dimensione di chiavi e messaggi, incidendo su MTU e performance. Testa in anticipo per non "far saltare" la produzione sotto carico.

Errori comuni e anti-pattern

Chiavi statiche e PSK senza PFS

L’abitudine più pericolosa è usare chiavi statiche per "comodità" e prevedibilità. Un file, un segreto, decine di client. Comodo finché non c’è una fuga. Dopo, tutto l’archivio sessioni è nelle mani del nemico. Se usi PSK, fai solo in modalità con accordo effimero aggiuntivo e autenticazione per preservare PFS.

La migliore pratica è certificati con TLS moderno ed ECDHE o WireGuard con gestione semplice delle chiavi e forward secrecy integrata. Stagnazione solo se non c’è alternativa, con segmentazione rigorosa e cambio frequente.

Riutilizzo di parametri DH e RNG debole

Riutilizzare valori effimeri è un peccato mortale. RNG debole è peggio. Su VM senza entropia, container senza rngd, kernel vecchi – un rischio reale. La soluzione sono kernel moderni, librerie crittografiche affidabili, sorgenti hardware di entropia e inizializzazione precoce.

In parole povere, è meglio configurare correttamente il sistema di generazione casuale una volta per tutte che passare settimane a capire perché gli handshake sono diventati deterministici e ripetitivi.

Sessioni lunghe e risparmio "sui fiammiferi"

Risparmiare sul rekey è una brutta idea. Sessioni che durano giorni senza cambiare chiave allargano la finestra di rischio. Il carico degli handshake si può livellare e distribuire nel tempo con timer, ma lasciar vivere a lungo una chiave è una tentazione per gli attaccanti. Imposta la regola: la chiave è un consumabile, non un cimelio.

E non dimenticare di monitorare: raccogli metriche su riconnessioni, errori handshake, latenza. Dove vedi anomalie, regola i tempi con precisione. Gestisci, non indovinare.

FAQ: risposte rapide e chiare

Domande base

Qui trovi risposte semplici per spiegare rapidamente ai colleghi perché PFS conta adesso.

1. Cos’è Perfect Forward Secrecy in parole semplici? È un modo per impedire che la compromissione delle chiavi domani sveli le tue sessioni di ieri. Ogni sessione VPN è cifrata con una chiave unica usa e getta che sparisce alla fine.
2. Perché il traffico intercettato non si può decifrare in seguito? Perché la chiave di sessione non è legata alla chiave lunga del server. Nasce dallo scambio effimero (ECDHE) e non viene mai salvata. Senza chiave non c’è niente da rubare retroattivamente.
3. Quali protocolli VPN supportano PFS nel 2026? WireGuard di default, OpenVPN con ECDHE, IKEv2/IPsec con PFS attivato in CHILD_SA, e qualunque servizio TLS 1.3 su cui si basano le VPN.

Domande tecniche

Per chi configura e vuole farlo bene al primo colpo.

1. Quali parametri scegliere per PFS affidabile? ECDHE con X25519, cifrari AEAD AES-GCM o ChaCha20-Poly1305, HKDF-SHA256. Per IKEv2: PFS con ECP256 o ffdhe3072 e rekey regolare.
2. Quanto impatta PFS sulle prestazioni? Su CPU moderne è minimo. Di solito 1-3% di overhead sull’handshake. Nelle sessioni lunghe non si nota quasi.
3. PFS aiuta contro attacchi quantistici? PFS riduce il valore degli archivi intercettati perché senza intervento al momento dello handshake non si possono aprire le vecchie sessioni. La protezione totale quantistica richiede handshake ibridi o post-quantistici, ora in fase di adozione.