OpenVPN EC vs ED: perché questi nomi non sono una scala di forza

Mettete ec, ed, ecdh, ecdsa, auth e una lista di cifrari TLS fianco a fianco in un unico profilo e il file comincia a sembrare una manopola della forza con sei posizioni. Non lo è. Ogni nome risponde a una domanda diversa, e due profili che differiscono in uno di essi non sono necessariamente più forti o più deboli l’uno dell’altro. Ordinare i nomi in base al lavoro che svolgono richiede circa cinque minuti ed evita la maggior parte delle cattive modifiche che le persone fanno a una configurazione funzionante.

L’ordinamento che segue parte dalla confusione stessa e poi si allarga verso le parti di un profilo che decidono davvero che cosa protegge il vostro traffico. Ogni sezione prende a turno un fraintendimento e mostra a che cosa è realmente legato il nome.

Due lettere, due domande diverse

La coppia che genera più discussioni è EC ed ED, e la discussione di solito presume che siano risposte rivali a un’unica domanda. Non sono nemmeno sullo stesso asse. EC descrive una famiglia di matematica: la crittografia su curva ellittica, dove la sicurezza deriva dalla difficoltà di un logaritmo discreto su una curva e non in un grande campo finito.

ED descrive una forma di curva all’interno di quella famiglia. Le curve Twisted Edwards sono una rappresentazione scelta per la velocità e per la resistenza a diversi errori di implementazione, e Ed25519 è il nome che le persone di solito intendono. La curva non è un concorrente della crittografia su curva ellittica; è un modo di scrivere una curva ellittica. Leggere ED come "l’EC più recente e più forte" è la prima svolta sbagliata, e tutto ciò che segue tende a essere sbagliato nella stessa direzione.

Firmare e scambiare sono compiti separati

Una volta risolta la questione della famiglia, i nomi rimanenti si dividono in due colonne che non si sostituiscono mai a vicenda. Una colonna firma, l’altra concorda un segreto condiviso.

Sia EdDSA sia ECDSA firmano, ma sono schemi diversi con formati di chiave diversi, quindi un certificato rilasciato per l’uno non è utilizzabile come l’altro. EdDSA è definito per un piccolo insieme di curve; P-256 non è una di queste, ed è per questo che un certificato P-256 si verifica con ECDSA e mai con Ed25519.

La colonna dello scambio non ha un equivalente chiamato EdDH. L’accordo effimero su una chiave Curve25519 è X25519, e questo è ECDH con una curva particolare, esattamente come con P-256. Ed25519 indica rigorosamente lo schema di firma, anche se il nome viene usato in modo disinvolto per lo scambio perché le due curve sono correlate: la forma Edwards usata per firmare e la forma Montgomery usata per X25519 descrivono lo stesso gruppo sottostante.

Perché un profilo EC non ha un file dh

Un file dh contiene parametri generati in anticipo per Diffie-Hellman a campo finito, e quei parametri esistono perché un grande numero primo e un generatore devono pur venire da qualche parte. Uno scambio su curva ellittica non ne ha bisogno: la curva nominata è l’insieme dei parametri, ed entrambe le parti lo conoscono già. È questa l’intera ragione per cui un profilo EC può omettere la direttiva.

Due situazioni producono ancora una riga dh in un profilo che per il resto sembra moderno. La prima è un secondo ascoltatore o un peer più vecchio che negozia davvero gruppi a campo finito. La seconda è testo residuo copiato da un modello dell’epoca RSA e mai rimosso. Un profilo che nomina una curva per lo scambio e carica ancora un file dh da 2048 bit non è più sicuro per questo; porta con sé un artefatto inutilizzato.

TLS 1.3 ha tolto lo scambio di chiavi dal nome

Confrontate TLS_AES_256_GCM_SHA384 con TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 e il nome più corto sembra un declassamento. È una ridenominazione, e la ragione è strutturale: TLS 1.3 ha rimosso RSA statico e lo scambio di chiavi Diffie-Hellman a campo finito, quindi uno scambio effimero su curva ellittica è l’unica opzione non PSK rimasta. Nominarlo in ogni suite ripeterebbe lo stesso fatto una dozzina di volte.

Il tipo di certificato è sparito dal nome per una ragione collegata. In 1.3 il certificato autentica la firma della stretta di mano, non l’accordo sulle chiavi, quindi non seleziona più la suite. È anche per questo che nella configurazione esiste una lista di cifrari separata per 1.3: le suite sono state rinominate e riorganizzate, non indebolite.

Una conseguenza merita di essere detta chiaramente. ECDHE è un algoritmo di scambio di chiavi e mai un cifrario. Una suite descritta come "ellittica" dice qualcosa su come i due peer sono arrivati a una chiave condivisa, e nulla su che cosa cifra poi il carico utile.

auth autentica i pacchetti, non i carichi utili

La direttiva auth seleziona il digest HMAC che autentica i pacchetti, e il suo valore predefinito storico è SHA1. Con un cifrario dati non AEAD, OpenVPN calcola il digest sul testo cifrato e lo aggiunge, una disposizione cifra-poi-MAC che è ciò che rende impraticabile manipolare il riempimento.

Il mito qui è che alzare auth a SHA512 renda più solido il tunnel. Non aumenta la forza della cifratura, e se il cifrario dati negoziato è una modalità AEAD come AES-256-GCM, il digest non viene affatto applicato ai pacchetti dati. Il tag GCM li autentica già, e il valore auth resta per l’HMAC del canale di controllo e per ogni cifrario non AEAD ancora in uso.

La direttiva conta dunque, ma conta in un punto più stretto di quanto suggerisca la sua posizione nel file. Verificare quale cifrario è stato realmente negoziato vi dice se si applica o no.

Leggete il profilo per colonna, non per rango

Tre domande separano nettamente gli strati, e a ciascuna risponde una parte diversa della sessione negoziata. Quale cifrario protegge il carico utile? Quale tag o digest garantisce per ogni pacchetto, e il cifrario in uso ne richiede davvero uno? Quale certificato ha chiuso la stretta di mano, e il canale di controllo è inoltre protetto da tls-auth o tls-crypt?

Niente nell’etichetta EC o ED risolve una di quelle tre domande, e un nome di suite da solo non ne risolve nessuna. Il risultato negoziato è l’unica prova, quindi leggetelo invece di dedurre la forza dal vocabolario:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Il primo comando vi dice quale schema di firma usa realmente il vostro certificato, ed è l’unico modo affidabile per sapere se state eseguendo ECDSA o Ed25519. Il secondo mostra la riga del canale di controllo che il client ha registrato per la sessione, compresi la versione TLS e la suite su cui si è fermato. Se una modifica al profilo non può essere giustificata da uno di questi due output, è probabilmente un cambio di nome e non di proprietà.