Chiave statica o TLS per un collegamento OpenVPN tra due peer?

Due macchine che parlano solo tra loro possono mantenere quella topologia e ottenere comunque chiavi di traffico negoziate. La forma della rete e la modalità di protezione sono scelte indipendenti, ed è confonderle che spinge le persone a provare a ruotare un segreto statico sostituendo un file mentre entrambi i demoni continuano a girare. Sostituire il file della chiave sotto una coppia in esecuzione non ruota nulla. La modalità a chiave statica, che OpenVPN 2.6 contrassegna come obsoleta, tiene un’unica chiave per tutta la vita del tunnel, quindi il file su disco e la chiave in memoria tornano a coincidere solo dopo il riavvio di entrambe le estremità. Se il requisito è il rinnovo automatico, la modalità di protezione deve cambiare.

Cosa non può fare la modalità a chiave statica

In modalità segreta, entrambi i peer condividono una chiave precondivisa che cifra e autentica direttamente il tunnel. Non c’è handshake, quindi non c’è alcun meccanismo che permetta a un lato di proporre nuovo materiale di chiave, dimostrare un’identità o riprendersi da una discrepanza senza l’intervento dell’operatore. Entrambe le proprietà derivano dall’assenza di un canale di controllo e non da un’opzione mancante, e nessun flag di configurazione ne aggiunge uno a questa modalità.

Il manuale di OpenVPN 2.6 è esplicito nel dire che la chiave persiste finché non ne viene generata una nuova. È accettabile per un collegamento di laboratorio o una coppia fissa di apparati con una procedura di rotazione documentata, ed è inaccettabile ovunque un segreto di lunga durata sia un rischio reale. Una sostituzione di file non crea una nuova chiave per una coppia in esecuzione; crea due peer in disaccordo. Sostituire il file aggiunge quindi un’interruzione senza aggiungere rotazione.

Non esiste nemmeno una nozione di identità del peer al di là del possesso del file. Chiunque detenga la chiave è un peer, e nulla nel tunnel registra quale lato sia quale, quindi la revoca è tutto o niente.

Passare a TLS senza ridisegnare il collegamento

La modalità TLS aggiunge un canale di controllo e, con esso, la capacità di negoziare le chiavi del canale dati. In una distribuzione punto a punto, un lato assume il ruolo di server e l’altro quello di client, ma la topologia resta un collegamento tra due peer: ogni lato conosce l’endpoint dell’altro e non compare alcun pool né servizio multiutente. I ruoli sono un dettaglio dell’handshake, non una nuova architettura.

Date a ogni macchina la propria identità. Ogni lato ha bisogno di un certificato e di una chiave privata, dell’ancora di fiducia che convalida l’altro e di una regola di verifica del peer che indichi chi è atteso. Non riutilizzate la chiave privata di un peer sull’altro per risparmiare tempo; ciò trasforma due identità in una e rimuove la possibilità di revocare ciascun lato separatamente. L’iscrizione è il luogo in cui farlo correttamente, perché correggerlo dopo significa riemettere certificati.

Mantenete invariato il contratto di rete mentre la protezione cambia. Gli stessi indirizzi del tunnel, le rotte e i servizi consentiti dovrebbero valere prima e dopo, così che un guasto durante la migrazione sia un problema di protezione e non una sorpresa di routing mascherata. Annotate gli indirizzi e le rotte prima della modifica; confrontarli dopo è più rapido che ricostruirli a memoria.

Alcune distribuzioni proteggono anche il canale di controllo con una propria chiave statica, che non ruota con il canale dati. Quella chiave custodisce l’handshake e non il carico utile, quindi comprometterla espone la negoziazione e non il traffico. Conservatela separatamente dal materiale del canale dati e assegnatele una data di sostituzione di cui è responsabile una persona nominata. Ruotarla significa riavviare entrambi i peer in una finestra coordinata, per questo merita una voce in calendario e non un ricordo.

Chi rinnova cosa, e quando

In modalità TLS, il rinnovo è guidato da limiti configurati: un intervallo di tempo, un conteggio di byte o un conteggio di pacchetti. Il controllo temporale documentato è ciò su cui si basa la maggior parte delle distribuzioni, e il valore effettivo più basso tra i due peer può avviare la sostituzione, quindi alzarlo su un solo lato non trattiene l’evento. I limiti basati sul volume esistono perché un collegamento trafficato può esaurire una chiave molto prima che lo faccia l’orologio. Nessuno dei due limiti è un controllo di salute e nessuno vi dice che un rinnovo è riuscito.

Per questo diagnosticare una rinegoziazione ricorrente da un solo file di configurazione è fuorviante. Leggete le impostazioni su entrambi i peer, poi guardate la transizione nel registro invece di supporre un guasto. Un rinnovo che si completa in modo pulito sembra una breve raffica di traffico del canale di controllo, non una disconnessione.

Tenete separati gli oggetti nella vostra testa. Il certificato prova l’identità a lungo termine e viene sostituito secondo un calendario che controllate voi. La chiave del canale dati viene aggiornata automaticamente, e uno scambio di autenticazione separato, se la distribuzione lo richiede, segue la politica dell’account e può richiedere proprie disposizioni per gli scambi successivi.

Disattivare del tutto il rinnovo, impostando l’intervallo a zero, non è una soluzione per un registro rumoroso. Trasforma un evento sano del ciclo di vita in una chiave permanente, il che vi riporta alla proprietà che stavate cercando di lasciarvi alle spalle.

Accettare il cambiamento

Costruite la nuova configurazione dall’esempio supportato della versione installata, non da un vecchio frammento minimo i cui algoritmi e percorsi dei file sono stati ereditati da altrove. Coordinate il passaggio perché entrambi i peer cambino insieme, e mantenete un percorso di ripristino approvato nel caso un lato non si avvii. Abbassate il collegamento deliberatamente invece di attendere un’interruzione per testare il rollback. Un rollback che avete provato vale più di un rollback che avete descritto.

Testate tre cose: la verifica iniziale dell’identità riesce, il flusso applicativo previsto funziona e un rinnovo controllato avviene senza perdere traffico. Poi leggete la transizione nel registro per ciò che dimostra davvero: un nuovo identificatore di chiave significa che i peer hanno completato una sostituzione, non che il tunnel si è riconnesso. Trattatela come prova di un singolo passo e controllate i contatori di traffico prima di dichiarare conclusa la migrazione.

Ciò che una promessa di zero interruzioni nasconderebbe è il guasto che non avete ancora visto. Un rinnovo che fallisce, un certificato che scade o un difetto di percorso possono ancora disturbare il collegamento, e nessuno di essi è escluso da un’esecuzione di test pulita. La proprietà per cui vale la pena progettare è più ristretta e più utile: la sostituzione ordinaria delle chiavi smette di essere uno scambio manuale di file.