File DH o chiave tls-auth? Distinguere due file di OpenVPN

Due file, due direttive e l’abitudine di nominarli entrambi come la cosa che configurano. È così che un dh.pem finisce su una riga tls-auth e il client fallisce con un messaggio su un formato di chiave inatteso. La decisione davanti a te non è quale file sia più forte. È quale ruolo serva davvero al deployment, e tre condizioni la risolvono: quale scambio di chiavi negozierà il tuo stack TLS, se vuoi l’autenticazione del canale di controllo o no, e se il materiale debba restare segreto.

Rispondi a queste in ordine e la domanda del file si risponde da sola. Salta e i nomi delle direttive iniziano a sembrare intercambiabili, che è esattamente lo stato da cui nasce l’errore.

Leggi l’etichetta prima del nome del file

La prima riga del file è più informativa del suo nome, perché un nome è una convenzione umana e l’etichetta la produce lo strumento. I parametri Diffie-Hellman portano un’etichetta PEM BEGIN DH PARAMETERS. Una chiave statica OpenVPN è una struttura del tutto diversa, con la propria intestazione e il proprio carico esadecimale.

Rinominare non converte nulla. Un file di parametri chiamato ta.key resta parametri, e una chiave statica chiamata dh.pem resta una chiave statica; il parser legge il contenuto e rifiuta la discrepanza. Controlla prima di modificare il profilo:

head -n 1 dh.pem
head -n 1 ta.key

Tre condizioni che decidono quale file ti serve

La prima condizione è lo scambio. Un handshake Diffie-Hellman a campo finito ha bisogno di un gruppo, e la direttiva dh è dove il server nomina i parametri per esso. Un handshake su curva ellittica non ha affatto bisogno di quel file, perché la curva è l’insieme di parametri. Se il tuo server negozia solo suite ECDHE, un file DH è peso morto anziché forza aggiuntiva.

La seconda condizione è l’autenticazione del canale di controllo, una funzione separata con materiale proprio. Un file tls-auth è una chiave statica condivisa che entrambi i peer detengono, usata per firmare i pacchetti del canale di controllo così che un peer non autenticato non possa nemmeno completare l’handshake. Esiste sia che tu usi DH a campo finito sia che no, e non ha nulla a che vedere con i parametri di gruppo.

La terza condizione è il segreto e la distribuzione. I parametri DH possono essere pubblicati senza indebolire la sessione, perché i valori segreti vengono generati per ogni handshake e non lasciano mai i peer. Una chiave statica non deve essere pubblicata: sono gli stessi byte su entrambi i lati, non ruota da sola e chiunque la detenga può produrre firme valide del canale di controllo. Quelle due risposte portano a regole di gestione completamente diverse, ed è per questo che un file può stare in un repository e l’altro no.

Genera il materiale giusto per ogni ruolo

Usa lo strumento che produce il formato atteso dalla direttiva invece di convertire tra i due. Per la chiave condivisa su OpenVPN 2.6, la forma tipizzata del generatore dichiara esplicitamente lo scopo.

openvpn --genkey tls-auth ta.key

Quel comando crea nuovo materiale segreto; non ripara né ispeziona una chiave esistente, e rieseguirlo ti dà una chiave diversa che gli altri peer non hanno. Copia il file risultante ai peer che ne hanno bisogno attraverso un canale che useresti per qualsiasi segreto condiviso, e mantieni coerente la convenzione di direzione: con tls-auth, un lato usa key-direction 0 e l’altro key-direction 1.

I parametri DH, quando servono, provengono dalla generazione di parametri e non da un generatore di chiavi, e la loro provenienza conta anche se l’output è pubblico. Un gruppo preso da una fonte sconosciuta non diventa affidabile per il fatto di essere pubblico; deve comunque essere un gruppo su cui i tuoi peer concordano e che non sia indebolito dalla sua dimensione o costruzione.

Che cosa fa dh none e che cosa non fa

dh none è una direttiva reale dal significato ristretto: nessun file di parametri a campo finito verrà caricato, perché l’handshake usa Diffie-Hellman su curva ellittica. Non è un’abbreviazione di «salta il passo DH» nel senso di indebolire qualcosa, e certamente non dice a OpenVPN di accettare un altro file come sostituto.

Da una lettura sbagliata derivano due errori. Il primo è supporre che dh none elimini la necessità di tls-auth, mentre i due controllano cose diverse. Il secondo è tenere una riga dh obsoleta accanto a una configurazione solo curva e poi chiedersi quale file stia davvero usando il server; se la direttiva è presente, il file viene letto, e un percorso rotto lì fa fallire l’avvio per un motivo senza rapporto con lo scambio che verrà negoziato.

Se il file sbagliato è già stato distribuito

Ripristina il segreto previsto dal proprietario del profilo e non toccare la verifica del certificato mentre lo fai. Il guasto è una discrepanza di formato, non un guasto di fiducia, e disattivare la verifica per superare l’errore sostituisce un problema di avvio con uno silenzioso.

Poi separa i due incidenti che le persone tendono a fondere. Pubblicare un file di parametri DH è quasi innocuo, perché i parametri erano pubblici per progettazione. Esporre la chiave tls-auth è un altro evento: la chiave autentica i pacchetti del canale di controllo per ogni peer che la detiene, quindi la sostituzione va coordinata su tutto il deployment e non applicata a un solo host.

Un controllo di cinque minuti stabilisce in quale caso ti trovi: leggi la prima riga di ogni file, conferma la direttiva che lo referenzia e conferma che la distribuzione del file corrisponda a ciò che il materiale richiede. È un lavoro più piccolo che rigenerare una PKI funzionante, ed è quello a cui le tre condizioni puntavano fin dall’inizio.