Perché openssl rand non può creare la chiave che tls-crypt vuole

OpenSSL è già installato, l’host ha entropia, e generare una chiave con esso sembra la scorciatoia ovvia. L’output sarà casuale e segreto e del tutto inutilizzabile, e il guasto arriva come errore del canale di controllo anziché come qualcosa che menzioni un formato di chiave. Quella falsa pista è la parte costosa, perché manda le persone a ispezionare i loro cifrari. Ciò che la VPN legge è una struttura di file precisa, non un blocco arbitrario di byte, e una variante della funzione non può essere prodotta affatto fuori dal server.

Che cosa deve essere realmente il file su disco

Un file di chiave statica di OpenVPN è testo. Inizia con una riga di commento che dichiara che cos’è, porta dati esadecimali su righe di larghezza fissa e totalizza 256 byte di materiale di chiave. OpenVPN lo legge come il segreto condiviso del canale di controllo, non come un certificato, non come una passphrase e non come qualcosa che una libreria TLS riconoscerebbe.

Lo stesso tipo di oggetto serve entrambe le funzioni del canale di controllo. Con tls-auth, ogni peer ha bisogno anche di una direzione perché i pacchetti di un lato non possano essergli riflessi contro. Con tls-crypt, un unico segreto condiviso cifra e autentica il canale di controllo in entrambe le direzioni, il che nasconde la stretta di mano oltre a proteggerla.

Niente di tutto ciò è conoscenza segreta, e il formato non è il punto. Il punto è che il file deve corrispondere esattamente a ciò che il lettore si aspetta: intestazione, larghezza di riga, ritorno a capo finale e lunghezza totale. Un file sbagliato di una riga si carica come spazzatura o fallisce del tutto. Confrontare due peer byte per byte è quindi un primo test legittimo, ed è più veloce che leggere uno qualsiasi dei due file di configurazione.

Il modo supportato per crearne uno

Genera la chiave statica semplice con lo strumento che la consumerà, poi referenziala da entrambe le estremità:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

L’ortografia dell’opzione è cambiata nel tempo: le installazioni più vecchie dell’era 2.4 usavano una forma con un flag separato prima del nome del file, mentre le build attuali accettano quella più corta. In ogni caso il file risultante è lo stesso tipo di oggetto, quindi il controllo è se entrambi i peer detengono byte identici.

La seconda generazione aggiunge una struttura che nessun generatore esterno può inventare. Una chiave server viene creata una volta, e ogni client riceve una chiave avvolta derivata da essa:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Ciò che il client riceve non è la chiave del server stesso duplicata. È un oggetto avvolto che porta metadati che solo il server può svolgere, ed è quell’avvolgimento il motivo per cui un file per dispositivo può essere revocato senza toccare nessun altro dispositivo. Tieni la chiave server sul server e trattala come la radice di quella fiducia per dispositivo.

Dove i byte fatti a mano si rompono

Stampare 256 byte casuali come esadecimale sotto un’intestazione corretta darebbe, in teoria, un file di chiave statica che si carica. Resta una cattiva idea. Ogni dettaglio di formattazione diventa un’occasione per produrre materiale che fallisce al caricamento o, peggio, lascia due peer con valori diversi che si rivelano solo come un errore di autenticazione.

Niente di equivalente è possibile con la variante v2. Una chiave client avvolta esiste solo come output del processo di chiave del server, e il server conserva il materiale necessario per svolgerla. Un blob casuale verrà rifiutato o semplicemente non riuscirà a decifrare, e nessuno dei due messaggi menzionerà la casualità.

La compatibilità delle versioni sta sopra tutto questo. La prima generazione richiede una versione che la supporti a entrambe le estremità, e la seconda richiede di nuovo una versione più recente. Un client compilato prima che la funzione esistesse non può completare una stretta di mano con un server che accetta solo materiale avvolto, e il guasto che segnala punta al canale di controllo anziché alla versione.

Ruotare senza chiudere fuori tutti

Ruotare un unico segreto condiviso è un esercizio di coordinamento, non tecnico. Ogni client ha bisogno del file sostitutivo in mano prima che il server ritiri il precedente, e qualsiasi macchina che conservi ancora il vecchio valore fallisce nel momento in cui ciò accade. Non iniziare quella rotazione a metà di una giornata lavorativa.

Con la disposizione v2, la rotazione è per dispositivo: emetti una nuova chiave avvolta per una macchina e ritira la vecchia solo per quella macchina. È l’argomento principale per passare una volta che ogni client è su una versione che la supporta.

I permessi dei file appartengono alla stessa conversazione. La chiave dovrebbe essere leggibile solo dall’account che esegue il servizio, e non dovrebbe risiedere nello stesso repository dei profili che protegge. Il riferimento di OpenVPN 2.6 documenta le forme di generazione e le sezioni sul materiale della chiave, che è una fonte migliore di un comando copiato da un post di un forum.