Un certificato RSA può funzionare con dh none in OpenVPN?

Ecco una configurazione del server che dice dh none accanto a un certificato che dice RSA, più il sospetto insistente che uno dei due debba essere sbagliato. Niente è sbagliato. Il certificato firma e autentica; lo scambio di chiavi stabilisce un segreto condiviso. Sono due compiti diversi nello stesso handshake, e TLS consente a un certificato RSA di autenticare un handshake che usa un accordo effimero su curva ellittica.

La confusione di solito arriva con una guida alla migrazione. Dice di sostituire il file dei parametri DH con dh none, il lettore nota che il certificato non è un certificato di curva ellittica, e i due fatti vengono trattati come una contraddizione.

Perché le due impostazioni sembrano collegate

La configurazione più vecchia di OpenVPN richiedeva un file di parametri DH perché Diffie-Hellman su campo finito ha bisogno di parametri di dominio su cui entrambe le parti concordano. La direttiva dh puntava a quel file. Quando un deployment passa a ECDH, i parametri provengono invece da una curva con nome, e il file non serve più, che è ciò che esprime dh none.

I certificati sono un asse separato. Portano una chiave pubblica e una firma che provano l'identità del server, e quella chiave può essere RSA o a curva ellittica indipendentemente da come viene concordata la chiave di sessione. Un handshake che usa ECDHE per l'accordo della chiave e RSA per l'autenticazione è comune e ampiamente distribuito.

La nomenclatura peggiora la sovrapposizione. La curva ellittica compare sia nei nomi delle suite ECDHE sia in quelli ECDSA, quindi è facile supporre che qualsiasi connessione che menzioni una curva debba includere un certificato di curva. Non è così.

Leggere correttamente il nome di una suite TLS 1.2

Prendete ECDHE-RSA-AES256-GCM-SHA384. Il primo token è la famiglia di scambio delle chiavi: Diffie-Hellman effimero su curva ellittica. Il secondo è la famiglia di autenticazione: RSA. Il resto descrive la protezione dei record e l'hash usato nell'handshake.

Una suite ECDHE-ECDSA usa la stessa famiglia di scambio delle chiavi con un metodo di autenticazione diverso, quindi richiede un certificato di curva ellittica. Una suite DHE-RSA usa Diffie-Hellman effimero su campo finito con autenticazione RSA, e quella sì richiede parametri DH.

Leggete il nome di una suite da sinistra a destra e assegnate ogni parte al suo compito. Una volta separati i token, la domanda cambia da «il mio certificato corrisponde a dh none» a «il mio server consente una suite il cui scambio di chiavi non richiede un file DH».

Che cosa disattiva davvero dh none

dh none dice al server di non caricare un file di parametri DH su campo finito. Non disattiva l'autenticazione, la validazione dei certificati né TLS stesso. Richiede però che lo scambio di chiavi negoziato non abbia bisogno di quei parametri, il che in pratica significa una suite ECDHE o un handshake TLS 1.3.

Da questo requisito nasce il guasto. Se la politica dei cifrari TLS del server è limitata alle suite DHE, o se un client offre solo quelle, rimuovere il file dei parametri non lascia alcun metodo di scambio delle chiavi utilizzabile e l'handshake fallisce. L'errore compare di solito durante l'handshake del canale di controllo, prima di qualsiasi autenticazione utente. Leggete la lista dei cifrari prima di dare la colpa al file mancante.

Dal lato della curva ellittica, la curva è scelta dalla configurazione TLS del server, e OpenVPN offre un'opzione per sceglierla sui rami più vecchi. TLS 1.3 gestisce la negoziazione del gruppo all'interno del protocollo e non consulta affatto il file DH.

dh none non è di per sé un abbassamento della sicurezza. La forza dello scambio dipende allora dalla curva e dalla suite realmente negoziate, per questo il passo successivo è guardare ciò che hanno scelto i peer e non il file assente.

Confermare la negoziazione prima di modificare

Aumentate la verbosità del server e del client e leggete la riga del canale di controllo che OpenVPN stampa dopo una connessione. Nomina la versione di TLS e il cifrario negoziato, e riporta il tipo di chiave del certificato del peer. Quella singola riga risponde alla domanda che il file di configurazione solo suggerisce.

Se mostra TLS 1.2 con una suite ECDHE-RSA e un certificato RSA, la combinazione è esattamente ciò che dh none si aspetta, e non c'è nulla da riparare. Se mostra una suite DHE o un fallimento dell'handshake senza cifrario comune, la correzione è nella politica dei cifrari o nelle capacità del client, non nel certificato.

Provate il client più vecchio che intendete supportare, perché un client attuale può negoziare TLS 1.3 mentre uno più vecchio è limitato alle suite TLS 1.2. Se il client più vecchio non ha sovrapposizione, ampliate le suite consentite o aggiornate quell'endpoint.

Non disattivate la verifica dei certificati per superare un fallimento dell'handshake. Il fallimento vi dice che i peer non sono riusciti a concordare uno scambio di chiavi, e disattivare il controllo rimuove la garanzia di identità senza risolvere l'accordo.

Lista di controllo: il certificato è RSA, è consentita una suite ECDHE, il log mostra quella suite e anche il client supportato più vecchio la negozia? Se tutte e quattro le risposte sono sì, dh none fa il suo lavoro.