Perché una chiave OpenVPN più grande non elimina il timer di rinegoziazione

Scegliere AES-256 o una chiave più lunga non dice nulla su per quanto tempo quella chiave possa essere usata. La forza della chiave descrive l'algoritmo; la politica di rinegoziazione decide quando la sessione deriva nuovo materiale di chiave. Un'installazione può scegliere il cifrario più forte disponibile e sbagliare comunque il rinnovo, perché le due decisioni vengono prese in luoghi diversi. Confonderle produce un cambio di cifrario inutile oppure una sessione che sopravvive in silenzio alla propria politica.

Leggete le impostazioni di rinegoziazione prima di toccare il cifrario, e leggete entrambi i peer quando lo fate.

La forza della chiave e la durata della chiave rispondono a domande diverse

Il cifrario e la dimensione della chiave limitano quanto costerebbe un attacco al traffico intercettato. L'intervallo di rinegoziazione limita quanto traffico protegge una chiave e per quanto tempo una chiave compromessa resta utile. Sono controlli indipendenti, e un cifrario più forte non allunga la vita sicura di una sessione. La maggior parte delle guide che dicono 'usate AES-256' tace sul rinnovo, perché il rinnovo è una questione di politica e non una scelta di algoritmo.

Annotate entrambe le cose nelle note di installazione: cosa protegge il canale dati e cosa provoca la sostituzione delle sue chiavi.

La rinegoziazione ha tre trigger, e ciascun peer può attivarli

OpenVPN 2.6 documenta trigger separati per la rinegoziazione basati su byte, pacchetti e tempo trascorso. Il trigger temporale è quello che la maggior parte delle installazioni lascia al valore predefinito, il che significa che un tunnel silenzioso rinegozia comunque secondo il calendario. Ciascun peer può avviare lo scambio, e il peer che non l'ha avviato lo segue. Cambiare il timer su un lato non fissa quindi il comportamento della sessione; il valore effettivo è quello del lato che avvia per primo.

I trigger per byte e pacchetti contano per carichi ad alto throughput o a pacchetti piccoli, dove una politica solo temporale lascerebbe una chiave proteggere molti più dati del previsto. Se questi contatori restano disattivati, ditelo deliberatamente nelle note invece di lasciare il valore predefinito senza esame.

Una rinegoziazione espone il flusso di autenticazione

Una rinegoziazione è un nuovo handshake TLS, il che significa che il percorso di autenticazione viene eseguito di nuovo. Le installazioni con codici monouso, token hardware o una sfida RADIUS lo scoprono nel modo peggiore: la prima connessione funziona e la sessione muore un'ora dopo, quando il secondo handshake chiede un codice già usato. auth-gen-token esiste per colmare quel divario consentendo al server di emettere un token di breve durata per la rinegoziazione invece di pretendere un nuovo accesso interattivo.

Trattatelo come un problema di flusso di lavoro da risolvere con l'operatore, non come prova che il rinnovo debba essere disattivato.

Provate il rinnovo sotto carico, non in una sessione di un minuto

Un test di accettazione che si connette, fa un ping e si disconnette non raggiunge mai la rinegoziazione. Eseguite una sessione abbastanza lunga da superare il trigger configurato, tenete un trasferimento in corso per tutta la durata e osservate i log di entrambi i peer per il nuovo handshake. Poi provate il percorso di errore: cosa fa il client se la rinegoziazione non può concludersi. Un tunnel che cade in modo pulito è più facile da diagnosticare di uno che continua a inviare in una sessione morta.

Non leggete un trasferimento grande riuscito come prova di una soglia crittografica. Mostra solo che il percorso e i contatori hanno retto quel volume di traffico.

Documentate entrambe le scelte

Il registro richiede due righe: come sono protetti i pacchetti e quando quella protezione viene sostituita. Aggiungete l'autorità di ciascun valore, perché il cifrario può venire da un valore predefinito della distribuzione mentre il timer viene da una politica interna. Un operatore futuro non dovrebbe dover dedurre nessuno dei due da un file di configurazione.

Se la compatibilità impone un'eccezione, limitatela a una versione e a una data di fine. Un'eccezione che sopravvive alla sua ragione diventa la politica che nessuno ricorda di aver scelto.