Perché AES-256 non descrive una suite di crittografia VPN

Chiedete quale crittografia usa una VPN e la risposta arriva di solito in una parola: AES-256, oppure ChaCha20, o forse WireGuard. Quella risposta nomina un componente di un livello, mentre ciò che protegge davvero la connessione è un insieme di algoritmi che coprono quattro ruoli diversi. Confondere il componente con la disposizione è l’errore più comune in queste conversazioni e produce confronti che non si possono risolvere.

Quattro compiti dentro una connessione

La crittografia di massa trasforma il testo in chiaro in testo cifrato per il canale dati, e la sua chiave viene derivata invece che trasmessa. La protezione dell’integrità rileva modifiche, che è un compito separato anche quando una sola costruzione fa entrambe le cose. Lo stabilimento delle chiavi produce il materiale di traffico condiviso, e l’autenticazione del peer decide chi c’è dall’altra parte. Se ne manca uno, la connessione non è sicura, per quanto sia forte il pezzo rimasto.

Alcuni progetti fondono due ruoli in uno. AES-GCM e ChaCha20-Poly1305 sono costruzioni di crittografia autenticata, quindi riservatezza e integrità arrivano insieme; AES-CBC no, e richiede un codice di autenticazione del messaggio separato con la propria chiave. Per questo leggere una proposta come un sacco di numeri indipendenti legge male quelli progettati come coppie.

I ruoli stanno anche su livelli diversi, ed è per questo che la stessa parola può significare cose diverse in due prodotti. Un cifrario a blocchi dentro ESP e un cifrario a blocchi dentro TLS sono la stessa primitiva in negoziazioni diverse con requisiti diversi. Per questo citare una primitiva senza il suo modo e il suo livello può essere peggio che non citare nulla.

Perché il nome di un cifrario non dice quasi nulla

Prendete sul serio per un momento la frase AES-256: identifica un cifrario a blocchi e una dimensione della chiave. Non dice nulla sul modo di funzionamento, se l’integrità è fornita, né su come sono state stabilite le chiavi o autenticato il peer. Due prodotti possono entrambi pubblicizzare AES-256 e differire in tutto il resto, compreso uno che lo abbina a un modo non autenticato e un altro che usa un modo AEAD con scambio di chiavi moderno.

TLS 1.3 ha portato questa separazione nello standard, che è una correzione utile per chiunque abbia imparato il vocabolario più vecchio. Le sue suite di cifratura nominano solo l’AEAD e l’hash, mentre i gruppi di scambio chiavi e gli algoritmi di firma vengono negoziati come parametri separati. Per questo un nome di suite TLS 1.3 non è confrontabile con un nome di suite TLS 1.2 a parità di condizioni, anche se entrambi compaiono nello stesso campo di un file di configurazione. Un revisore che confronta le due stringhe direttamente trae una conclusione che il protocollo non sostiene. Leggete anche il gruppo negoziato e i parametri di firma, altrimenti il confronto resta incompleto.

WireGuard sceglie la strada opposta ed elimina la negoziazione quasi del tutto: il protocollo fissa un insieme di algoritmi, quindi due implementazioni interoperano o no. È una scelta progettuale legittima, e significa anche che la domanda su quale suite negozi WireGuard non ha una risposta che valga un confronto. Se lo auditate, leggete la specifica una volta e poi auditate la gestione delle chiavi attorno invece della negoziazione.

Il livello decide il vocabolario

Un impiego di IPsec negozia due volte: una proposta IKE per il canale di controllo e una trasformazione ESP per i dati, e le due possono legittimamente differire. Leggere la prima e supporre che descriva la seconda è una fonte comune di confusione durante un audit, perché il file di configurazione menziona entrambe e quella interessante è la seconda.

Un nome disponibile in una libreria non viene implementato automaticamente per un altro percorso dati. Per questo l’affermazione che il nostro prodotto supporta AES-256 è più debole di quanto suoni, e per questo un problema di interoperabilità si risolve di solito trovando l’intersezione mantenuta invece di abilitare ogni algoritmo vecchio su entrambi i lati.

La specifica di TLS 1.3 è l’esempio pubblicato più chiaro della separazione, perché definisce la suite come una coppia e sposta il resto nella propria negoziazione. Una volta che quella forma è familiare, la proposta IPsec e l’unico insieme fisso di WireGuard si leggono come varianti della stessa idea.

Leggete il risultato negoziato, poi fermatevi

Una proposta configurata non è prova di ciò che due peer hanno scelto. La sessione viva porta la risposta, e ogni implementazione diffusa può riferirla senza catturare pacchetti.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Nell’output leggete gli algoritmi selezionati invece dell’elenco offerto. Se la risposta è più debole di quanto intendesse la politica, la correzione appartiene alla configurazione della proposta da un lato o dall’altro, e una discrepanza nelle implementazioni moderne si manifesta di solito come negoziazione fallita e non come declassamento silenzioso.

Poi ricordate cosa la suite non copre. Rotte, permessi delle applicazioni, registrazione e conservazione sono decisioni separate con la propria revisione, e una disposizione crittografica compatibile non dice nulla su di esse. La discussione sul cifrario vale la pena, ma risponde a una domanda più stretta di quella che la maggior parte delle persone pone davvero.

Tenete preciso il vocabolario e l’argomento si accorcia. Una suite è un insieme di ruoli su un livello, un cifrario è un componente, e il risultato negoziato è l’unica cosa che descrive la connessione che avete davvero. Tutto il resto nel confronto è decorazione.