Perché le chiavi del server e le credenziali utente richiedono proprietari separati

La chiave che dimostra che il tuo gateway è se stesso e la credenziale che dice che una persona può unirsi sono entrambi segreti, ed è lì che finisce la somiglianza. Uno identifica un servizio davanti a ogni client; l’altro identifica un utente davanti a quel servizio. Mescolarli risparmia un passaggio durante l’installazione e costa un pomeriggio durante un incidente, perché il ripristino di ciascuno non è la stessa operazione. La separazione è noiosa da impostare e memorabile da omettere.

Due segreti, due proprietari diversi

Il gateway detiene una chiave privata o un certificato il cui unico compito è dimostrare la propria identità durante la stretta di mano. I client hanno bisogno del materiale pubblico corrispondente per verificarla, e non hanno mai bisogno della metà privata. È questa asimmetria che rende possibile l’autenticazione del server senza dare a ogni utente la capacità di impersonare il server.

Il materiale utente va nella direzione opposta. Una chiave privata client, un certificato client o una password dimostrano che a questa persona o dispositivo è stato concesso l’accesso. Ci si aspetta che venga distribuito, copiato tra dispositivi e infine revocato.

WireGuard rende ovvia la separazione perché ogni partecipante ha una coppia di chiavi: la chiave privata del server resta sul server, e un file di configurazione che dai a un utente contiene la sua chiave privata più la chiave pubblica del server. Un profilo che contiene la chiave privata del server non è una scorciatoia, è una compromissione in attesa di una condivisione di file.

Tre domande che decidono la separazione

Chiedi chi deve poter leggere il segreto, cosa permetterebbe a un attaccante un’esposizione e se la correzione sia una revoca o una ricostruzione del servizio.

Se un utente può leggerlo e questo dimostra l’identità del gateway, la risposta alla seconda domanda è che l’attaccante può impersonare il tuo server davanti a ogni client — il risultato peggiore, perché i client sono progettati per fidarsi di quell’identità. Se dimostra solo un utente, l’esposizione concede a quell’utente l’accesso a un peer, e la revoca è un’operazione di routine. Se è una chiave di un’autorità di certificazione, l’esposizione è peggiore di entrambe, poiché l’attaccante può coniare identità di cui si fida ogni endpoint.

Queste tre risposte producono la regola di archiviazione: la chiave CA vive offline o in una cassaforte, la chiave del gateway vive sul gateway, e le chiavi utente vivono con gli utenti. Qualsiasi disposizione che metta tutte e tre in un’unica directory per comodità ha trasformato una decisione in un incidente.

Ciò di cui un client ha davvero bisogno

Un client ha bisogno del certificato pubblico o della chiave pubblica del peer, del materiale CA o dell’impronta a cui deve fidarsi, della propria chiave privata e dei dettagli dell’endpoint. Quell’elenco non contiene nulla che appartenga all’identità privata del gateway.

La documentazione è dove questo trapela. Una guida che dice copia la directory del server ed elimina ciò che non ti serve ha già insegnato il modello sbagliato, perché il file che resta dopo il passaggio di eliminazione raramente viene controllato da qualcuno.

Revoca un utente senza toccare il gateway

Poiché le identità utente vengono emesse separatamente, possono essere ritirate separatamente. Un deployment basato su certificati revoca il certificato client e pubblica un elenco di revoca aggiornato; un deployment WireGuard rimuove la voce del peer dalla configurazione del server. Nessuna di queste operazioni cambia la chiave propria del gateway.

Conserva il registro delle emissioni, altrimenti non saprai quale identità ritirare. Un foglio di calcolo basta, purché nomini la persona, il dispositivo, il numero di serie o la chiave pubblica e la data, e purché qualcuno se ne occupi dopo che la persona che l’ha costruito è andata via.

I comandi seguenti ispezionano un certificato client e poi lo revocano tramite un’autorità in stile OpenSSL, che è il flusso che easy-rsa avvolge:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Pubblica il nuovo elenco dove i client lo controllano, altrimenti la revoca è una nota in un file che non cambia nulla. Se il tuo gateway accetta certificati client senza consultare un elenco di revoca, dillo esplicitamente invece di lasciar intendere che la revoca funzioni.

Tieni i backup separati quanto i segreti

Un archivio di ricostruzione contiene legittimamente la chiave del gateway e il materiale CA, perché senza di essi un ripristino non può riprodurre il servizio. Un pacchetto di installazione client non deve, e i due non devono essere archiviati insieme. Etichetta ogni archivio in base a chi può detenerlo, non alla data di creazione. Quell’etichetta è ciò che legge un amministratore stanco alle due del mattino.

Questa distinzione stabilisce anche chi può recuperare ciascuno. Amministrare il gateway, emettere identità utente e leggere i backup sono tre poteri diversi, e chi ne ha bisogno di uno non ha automaticamente bisogno degli altri. Scrivi quelle autorizzazioni, poi controllale rispetto a ciò che il tuo archivio consente davvero, perché l’ereditarietà delle directory concede in silenzio più di quanto la politica intenda.