Come OpenVPN data-ciphers sceglie il cifrario del canale dati

Il tunnel sale, il log mostra un cifrario e la revisione del profilo prosegue. Poi arriva un aggiornamento su un peer e lo stesso profilo fallisce con un messaggio sull'assenza di un cifrario condiviso, il che manda le persone a cercare una direttiva da eliminare. La cosa utile da capire è che data-ciphers descrive una negoziazione, non un'impostazione. Un lato offre un elenco, l'altro sceglie da lì, e il risultato è un solo algoritmo che entrambi supportano. Leggere quello scambio spiega la maggior parte di questi guasti prima che cambiate una riga.

Due canali, due configurazioni

Una OpenVPN sessione ha un canale di controllo e un canale dati. Il canale di controllo esegue la stretta di mano TLS che autentica i peer e negozia le chiavi. Il canale dati cifra i pacchetti che trasportano il vostro traffico.

data-ciphers configura il secondo. Il canale di controllo ha le proprie opzioni, e i controlli di identità del profilo sono una terza questione, separata. Modificare l'uno non corregge l'altro, perciò un profilo può sembrare corretto e fallire comunque a una certa fase.

Tenete i tre in caselle separate quando leggete un file di configurazione.

Leggete la negoziazione dal log

Il log del client nomina entrambi i risultati quando la connessione riesce. Una riga riporta il canale di controllo e i suoi dettagli TLS, e un'altra riporta il cifrario del canale dati che è stato selezionato.

Leggete entrambe, perché rispondono a domande diverse. Un guasto del canale di controllo ferma la connessione prima che qualsiasi cifrario dati conti. Una discrepanza del canale dati compare dopo una stretta di mano riuscita, con un messaggio sull'assenza di un cifrario condiviso.

Poi confrontate gli elenchi offerti su entrambi i lati. Un nome che la versione di un peer o il suo retroterra crittografico non fornisce non può essere selezionato, per quanto presto compaia nell'elenco dell'altro peer.

Come avviene davvero la selezione

Il server spinge il proprio elenco data-ciphers al client durante la stretta di mano, e il client seleziona la prima voce di quell'elenco che supporta anche lui. L'ordine appartiene quindi alla configurazione del server, non a quella del client.

Questo dettaglio spiega una classe di risultati confusi. Riordinare l'elenco del client non cambia nulla finché decide l'elenco del server. Aggiungere un cifrario che il client non può fornire non cambia nulla neppure, perché il client deve poter usare la voce che sceglie.

Le versioni più recenti hanno cambiato l'elenco predefinito e rinominato l'opzione che lo conteneva, così due peer su versioni diverse possono non trovarsi d'accordo senza che nessuno modifichi un profilo. Controllate la versione su ciascun lato prima di supporre un errore di battitura.

Un elenco non è una classifica di forza in astratto. È un insieme di candidati, e quello selezionato è la prima voce supportata da entrambi nell'ordine del server. Per questo due elenchi che sembrano diversi possono negoziare lo stesso cifrario. Per questo anche due elenchi che sembrano identici possono fallire.

I peer più vecchi hanno bisogno di un ripiego deliberato

Un peer che non può negoziare affatto, perché è precedente al meccanismo o lo ha disattivato, ha bisogno di un accordo di compatibilità documentato. L'opzione di ripiego esiste proprio per quel caso e si applica ai peer che non partecipano alla negoziazione.

Non è la stessa cosa di abilitare ogni cifrario ereditato per far sparire un messaggio. Un elenco ampio indebolisce la sessione per ogni peer, compresi quelli che avrebbero negoziato qualcosa di forte.

Coordinate i due lati invece di modificare nomi di algoritmi non correlati. Se un aggiornamento del server ha rimosso una vecchia opzione, la correzione appartiene al piano delle versioni, non a una corsa sul client.

Mantenete intatta la verifica

Una discrepanza del canale dati non è un motivo per accettare un server non verificato. La verifica del certificato, il nome server atteso e le impostazioni di protezione del canale di controllo sono separati dalla scelta del cifrario e dovrebbero sopravvivere a qualsiasi cambio di compatibilità.

Registrate insieme il cifrario dati negoziato, la versione del client e la versione del server, così il confronto successivo parte da fatti e non dal file di profilo.

Dopo una correzione supportata, provate la connessione iniziale e una rinegoziazione, perché una sessione che si stabilisce una volta può ancora fallire quando le chiavi vengono rinnovate.

Se il tunnel si stabilisce e i siti continuano a fallire, il cifrario non è più il sospetto. Continuate con l'instradamento e il DNS. Ordine di lavoro: leggete entrambe le righe di log, confrontate entrambi gli elenchi, controllate le versioni, aggiungete un ripiego solo per un peer che ne ha bisogno, poi riprovate il percorso di rinnovo.