Definizione (scheda del glossario): tls-crypt-v2 è la modalità di cifratura del canale di controllo specifica per client di OpenVPN. Ogni client riceve una chiave tls-crypt univoca (Kc) più una copia incapsulata di quella chiave (WKc) cifrata con una chiave server condivisa. Alla connessione, il client invia WKc all’interno di un P_CONTROL_HARD_RESET_CLIENT_V3 pacchetto; il server estrae Kc e entrambi i peer cifrano quindi i pacchetti del canale di controllo con la chiave specifica del client anziché con un’unica chiave precondivisa di gruppo.

Diagram comparing pre-shared key VPN authentication concepts
Fonte: Wikimedia Commons — Lbutrico chiave precondivisa

Quando una schermata delle impostazioni OpenVPN o le FAQ di un provider menzionano “tls-crypt-v2,” stanno indicando un meccanismo di protezione del canale di controllo, non un cifrario del canale dati e non un protocollo VPN autonomo. Capire la differenza è importante per le flotte di grandi dimensioni e per i provider VPN in hosting: i classici --tls-auth and --tls-crypt condividono una chiave di gruppo tra tutti i client e i server. Se un peer viene compromesso, quella chiave condivisa smette di offrire una protezione significativa da DoS e dello stack TLS per tutti gli altri. tls-crypt-v2 mantiene condivisa la chiave di wrapping lato server, assegnando a ciascun client la propria Kc.

Da dove proviene il progetto

OpenVPN documenta la funzionalità in doc/tls-crypt-v2.txt e nella documentazione API generata del progetto per crittografia del canale di controllo (tls-crypt, tls-crypt-v2). Lo stesso schema specifico per client compare nella bozza Protocollo Wire OpenVPN sotto “Chiavi di crittografia specifiche per client,” che nota esplicitamente che le implementazioni esistenti chiamano la funzionalità tls-crypt-v2.

La motivazione è tanto operativa quanto crittografica. Le chiavi di gruppo condivise scadono più rapidamente all’aumentare del numero di client e un laptop perso può imporre una re-key di massa. Cifrando la Kc di ciascun client con una chiave del server e consegnando la WKc insieme al client, gli operatori possono revocare o ruotare i singoli client senza ridistribuire un’unica chiave statica per l’intera community. I server possono comunque accettare i legacy tls-crypt or tls-auth client durante la migrazione perché l’opcode V3 hard-reset segnala la nuova modalità.

SSL VPN topology showing client, network, and server roles
Fonte: Wikimedia Commons — Topologia SSL VPN

Ad alto livello il flusso è un cookie crittografato:

  1. Gli operatori creano una tls-crypt-v2 server chiave usata solo per avvolgere e svolgere le chiavi dei client.
  2. Per ogni client generano una Kc nuova, la avvolgono come WKc con la chiave del server e consegnano Kc || WKc al client (spesso come blocco PEM intestato BEGIN OpenVPN tls-crypt-v2 client key).
  3. Il primo pacchetto di controllo del client usa l'opcode P_CONTROL_HARD_RESET_CLIENT_V3 e trasporta WKc.
  4. Il server decifra WKc, carica Kc, esegue opzionalmente un tls-crypt-v2-verify script sui metadati e, da quel momento, entrambe le parti usano Kc per la protezione del canale di controllo in stile tls-crypt.

I metadati opzionali all'interno del blob wrappato possono trasportare controlli di policy anticipati (ad esempio hint sull'identità del client), così un server può interrompere handshake abusivi prima di eseguire un costoso lavoro TLS. Quell'interruzione anticipata è uno dei motivi per cui la funzione viene commercializzata per la resistenza DoS sui grandi sistemi multi-tenant. I grandi provider VPN ne traggono particolare vantaggio perché gli endpoint dei clienti compromessi non espongono più automaticamente una singola chiave di gruppo tls-crypt condivisa da cui dipendono tutti gli altri clienti per il filtraggio del canale di controllo.

Cosa protegge tls-crypt-v2 — e cosa no

tls-crypt-v2 cifra e autentica canale di controllo pacchetti: il traffico dell'handshake TLS che negozia chiavi di sessione e opzioni. Non sostituisce il cifrario del canale dati (AES-GCM, ChaCha20-Poly1305 e così via), non sceglie gli IP di uscita e non implementa una policy no-logs. Pensalo come un'armatura intorno al piano di controllo di OpenVPN, così che il rumore UDP non autenticato e le chiavi di gruppo rubate siano meno utili contro lo stack TLS.

Le note di rilascio di OpenVPN 2.7.8 (riassunte da Linux Compatible il 7 ottobre 2026) mostrano anche perché la robustezza attorno a tls-crypt-v2 conti ancora: una correzione della 2.7.8 ha impedito ai client di fidarsi ciecamente di una richiesta del peer di ritrasmettere una chiave client incapsulata quando non era disponibile materiale di chiave. La policy CRA dell'Italia ha trattato quella classe di problemi “un server malevolo può interrompere il client” come degrado della robustezza piuttosto che come una violazione della riservatezza degna di CVE, ma gli operatori vogliono comunque la patch su ogni client che parla tls-crypt-v2.

Come differisce da tls-auth e tls-crypt

  • tls-auth: Integrità solo HMAC sui pacchetti di controllo con una chiave statica condivisa; non cifra il canale di controllo.
  • tls-crypt: Cifra e autentica i pacchetti di controllo con una sola chiave di gruppo condivisa.
  • tls-crypt-v2: La stessa protezione in stile AEAD del canale di controllo di tls-crypt, ma con Kc per client e cookie WKc wrappati dal server.

Tutti e tre riguardano il canale di controllo. Confonderli con l'handshake Noise di WireGuard o con IKEv2 è un errore di glossario comune. WireGuard non usa tls-crypt-v2; gli utenti OpenVPN che abilitano WireGuard altrove sono su uno stack completamente diverso. Allo stesso modo, abilitare tls-crypt-v2 non aggiorna magicamente i cifrari obsoleti del canale dati né risolve le perdite DNS fuori dal tunnel.

Checklist pratica

  1. Se gestisci un server OpenVPN multi-client o una flotta di un provider VPN, preferisci tls-crypt-v2 a una singola chiave tls-crypt condivisa, così un client perso non avvelena l'intera chiave di gruppo.
  2. Mantieni la chiave di wrapping del server con backup offline e ruotabile; pianifica come riassegnare i file WKc quando quella chiave server cambia.
  3. Conferma che i client parlino effettivamente V3 hard-reset (build OpenVPN moderne) prima di disabilitare tls-auth/tls-crypt legacy sul server.
  4. Monitora OpenVPN 2.7.8+ per le correzioni di robustezza di tls-crypt-v2 anche quando una modifica non ha un ID CVE.
  5. Ricorda: un wrapping solido del canale di controllo non può rimediare a una password utente riutilizzata, a un portale di phishing o a una perdita DNS fuori dal tunnel.

In sintesi: tls-crypt-v2 è la risposta di OpenVPN a “come fanno i grandi deployment a mantenere la crittografia del canale di controllo senza una chiave statica condivisa catastrofica?” Impara il modello a cookie, tieni separate le questioni del canale dati e delle policy, e considera l'igiene delle chiavi per client parte delle operazioni VPN normali, non un'opzione esotica riservata alle sole enterprise.