Rinegoziazione della chiave, riconnessione o riautenticazione: quale serve?

Una sessione attiva da ore non manterrà le stesse chiavi per sempre, ed è voluto. Tre eventi diversi vengono chiamati rotazione delle chiavi: nuovo materiale di sessione sotto un’associazione esistente, una ricostruzione completa della connessione e una ripetizione del controllo d’identità. Ognuno ha un innesco, un costo e una firma di guasto diversi. Scegli quello sbagliato e la correzione o non fa nulla o abbatte il tunnel senza motivo.

La decisione dipende da quale livello è davvero scaduto.

Tre operazioni chiamate rotazione

Una rinegoziazione della chiave crea nuove chiavi di traffico all’interno della relazione di controllo esistente, usando il meccanismo definito dal protocollo. IKEv2 lo fa con una nuova associazione di sicurezza figlia, TLS 1.3 con un messaggio di aggiornamento della chiave e WireGuard con un nuovo handshake quando raggiunge i suoi limiti di tempo o di messaggi. Gli indirizzi del tunnel e l’identità autenticata restano dove erano.

Una riconnessione scarta la connessione e la ricostruisce dall’inizio, il che ripete l’assegnazione degli indirizzi, l’installazione delle rotte e ogni negoziazione del primo tentativo.

La riautenticazione ripete la prova d’identità stessa, che può comportare una credenziale, un certificato o un secondo fattore. Può avvenire con o senza riconnessione, a seconda del prodotto.

Cosa nota l’utente al rinnovo

Una rinegoziazione della chiave dovrebbe essere quasi invisibile. Gli identificatori di associazione cambiano, i contatori possono azzerarsi e le applicazioni mantengono i propri socket; una breve pausa in una direzione è normale durante lo scambio. Vedere un nuovo identificatore in un elenco di stato non è prova di un guasto. La riga di log che segue lo scambio è quella che ti dice se è terminato.

Una caduta reale al rinnovo punta a un punto preciso. Una mancata corrispondenza della proposta, una credenziale scaduta o un cambio di percorso producono ciascuno una riga di log diversa, e solo uno di essi si corregge regolando le durate.

Dove le tre divergono in pratica

Se l’unica cosa scaduta è il materiale di chiave, rinegozia. Se l’indirizzo del peer, la rotta o il binding NAT sono cambiati e i pacchetti non arrivano più, riconnetti. Se l’organizzazione richiede un controllo d’identità periodico, quella è riautenticazione e nessun ritocco delle durate la sostituisce.

I valori predefiniti dei protocolli di solito contengono la risposta giusta. WireGuard rinegozia dopo una soglia di tempo e di volume di dati senza alcuna azione dell’utente; le durate IKEv2 vengono negoziate per associazione figlia; i tunnel basati su TLS ruotano le chiavi dentro la sessione esistente. Alzare le durate per evitare un errore ricorrente rimanda il guasto e allunga l’esposizione se una chiave viene compromessa.

Un avvertimento conta per le sessioni lunghe: la sola frequenza non crea segretezza in avanti. La proprietà dipende da come le chiavi di sessione si rapportano ai segreti di lungo periodo e se le vecchie chiavi vengono distrutte, il che è una questione di progetto e implementazione, non un’impostazione.

Scegli i valori predefiniti, poi registra la fase

Mantieni i valori predefiniti del fornitore salvo che un requisito documentato dica il contrario, e cambia le durate su entrambi i peer se le cambi. Poi registra a quale fase è arrivato ogni evento, così l’occorrenza successiva si può confrontare con lo stesso punto dell’handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Dopo una correzione, esegui un rinnovo controllato e invia traffico applicativo nuovo attraverso la nuova associazione. Un tunnel che si dichiara stabilito ma non inoltra nulla è il guasto che questo controllo esiste per intercettare.