Questa chiave OpenVPN pubblicata è una CA, una chiave di peer o tls-auth?

Qualcuno segnala che la chiave VPN è pubblica, e quella frase nasconde tre situazioni completamente diverse. Può essere un certificato CA che ogni client dovrebbe avere, una chiave d’identità privata che non avrebbe mai dovuto lasciare una sola macchina, oppure un segreto condiviso del canale di controllo che entrambe le estremità devono custodire. La riparazione, l’urgenza e l’ampiezza del danno cambiano in ogni caso, quindi il primo compito è la classificazione e non l’azione. Se si sbaglia la categoria, ogni passo successivo è fatica sprecata.

Parti dalla direttiva, non dal nome del file

Leggi la configurazione attiva e individua quale direttiva punta al materiale in questione. Le opzioni TLS di OpenVPN usano ca per il materiale di certificato attendibile, cert per il certificato del peer locale e key per la chiave privata che gli appartiene.

I nomi dei file non dimostrano nulla. Un file chiamato key.pem può contenere un certificato, e un blocco incorporato nel profilo può contenere esattamente lo stesso oggetto di un file separato sul disco. Apri il file e guarda la sua intestazione invece di fidarti del nome. Quell’unica verifica elimina la maggior parte dell’ambiguità nel rapporto.

Se il profilo è un pacchetto PKCS#12, estrailo in un luogo controllato per vedere cosa contiene davvero. Un singolo pacchetto può portare un certificato, la sua catena e una chiave privata, il che significa che una fuga del pacchetto è una fuga di tutti e tre.

Scrivi la classificazione prima che qualcuno modifichi un file: oggetto, direttiva, quali peer lo detengono e chi può leggerlo. Da quella frase dipende il resto della risposta.

Un certificato CA è pensato per essere condiviso

Un certificato CA pubblico è materiale di fiducia. I client ne hanno bisogno per verificare il server, e distribuirlo è il caso normale e non un incidente. Pubblicarlo non pubblica la chiave di firma privata della CA, che è l’oggetto che permetterebbe a un attaccante di creare nuove identità.

Vale la pena dichiarare esplicitamente questa distinzione nel ticket, perché le due cose vengono continuamente confuse. La domanda a cui rispondere è se il file divulgato sia il certificato o la chiave di firma, e un’occhiata rapida al contenuto del file lo risolve. Un certificato porta una chiave pubblica e una firma; la chiave di firma non vi compare affatto.

La distribuzione merita comunque attenzione. I client dovrebbero ottenere il certificato tramite il canale approvato di consegna dei profili, non da un sito di incolla, e un certificato che arriva per una via non attendibile può essere sostituito in transito.

Una chiave di peer e un segreto tls-auth non sono

La chiave privata di un peer è materiale d’identità. Una volta copiata, il server non riesce più a distinguere il dispositivo previsto da chiunque ne detenga la copia, perché il possesso esclusivo era la proprietà che si dimostrava. Proseguire l’autorizzazione e la sostituzione sono decisioni del proprietario della VPN, non di chi ha trovato il file.

Un segreto tls-auth è una terza cosa. Aggiunge un’autenticazione HMAC attorno ai pacchetti del canale di controllo, così quelli autenticati in modo errato vengono scartati prima di uno scambio TLS, e non è né la chiave privata del peer né la chiave che cifra i dati dell’applicazione.

Se quel segreto condiviso è pubblico, la barriera che offriva è sparita per tutti quelli che lo possiedono. Non ne segue che ogni detentore superi i controlli di certificato e utente che stanno dietro, ed è per questo che la classificazione conta più del livello d’allarme. Dì quale barriera è caduta e dì quali restano.

Ripara il ruolo che è trapelato, non uno vicino

Un segreto condiviso non torna privato rinominando il file o nascondendo il link di download. Sostituire significa generare un nuovo valore e distribuirlo a ogni peer in un cambiamento coordinato, e sostituire solo un lato rompe l’accordo per tutti quelli che hanno ancora il vecchio valore.

Se l’identità di un peer è stata esposta, usa la procedura di revoca e di nuova registrazione dell’operatore per quell’identità. Cambiare la password di un account non correlato non invalida un certificato copiato, e nemmeno scambiare il file tls-auth.

Conferma che cosa applica davvero il server distribuito prima di affidarti a una qualsiasi di queste cose. Un elenco di revoca che non viene aggiornato, o un controllo di ruolo disattivato durante un’interruzione, cambiano del tutto la risposta. Leggi la configurazione in esecuzione e non la copia nel repository.

Giudica il traffico passato secondo i suoi termini

Un file esposto non dice da solo se le sessioni catturate in precedenza possono essere decifrate. Dipende dal metodo di stabilimento delle chiavi, dal materiale esposto e da quali registrazioni esistono, e sia «è andato perso tutto il traffico» sia «non è successo nulla» sono congetture senza quei fatti.

Non pubblicare un’altra copia della credenziale mentre chiedi a quale categoria appartiene. Condividi invece i nomi delle direttive e i metadati non segreti tramite il canale di supporto approvato.

La conclusione utile nomina l’oggetto, il suo ruolo, la protezione persa e l’azione coordinata necessaria. Qualsiasi cosa di più breve è un titolo e non una valutazione.