Righe di cifratura obsolete nei vecchi profili VPN: leggete prima di copiare

Questo profilo è stato scritto nel 2016, e si importa ancora e si connette ancora. È esattamente per questo che nessuno lo guarda. Il client che un tempo leggeva queste direttive è sparito da tempo, e la build attuale potrebbe interpretarne diverse in modo diverso.

Che un file sopravviva non significa che una configurazione sia aggiornata. Separare queste due idee è la maggior parte del lavoro.

Scoprite quale client ha scritto il profilo

Iniziate dall’emittente e dalla versione. Il significato di una direttiva è definito dall’implementazione che la legge. Una riga che un tempo sceglieva un algoritmo può diventare un elenco di riserva, un avviso o un errore grave. Quale versione la interpreta decide il risultato.

OpenVPN è l’esempio più chiaro. La versione 2.5 ha introdotto data-ciphers e cambiato il modo in cui la vecchia direttiva cipher partecipa alla negoziazione. Un profilo che porta solo cipher AES-128-CBC ora fa una proposta molto più ristretta di quanto intendesse il suo autore.

Leggete le note di versione per l’impostazione che ora avverte o fallisce. Un avviso nel registro è un fatto sulla build attuale, e vale più della memoria di chiunque sul perché la riga sia stata aggiunta.

Guardate cosa è stato realmente negoziato

Un’importazione riuscita dimostra l’analisi, non la politica. Il risultato negoziato compare nel registro del client dopo che la connessione è attiva. Può differire da entrambe le estremità del file di configurazione.

# OpenVPN: what did this session agree on?
sudo journalctl -u openvpn-client@office --since '5 min ago' | grep -i 'cipher\|Data Channel'

# which directives does the profile actually carry?
grep -n -E 'cipher|auth|tls-|dh ' office.ovpn

Un’importazione accettata che scarta silenziosamente una direttiva lascia un profilo che si legge in un modo e si comporta in un altro. È quella lacuna che spiega come un documento etichettato come irrobustito negozi qualcosa di più debole di quanto affermi il suo stesso testo. Il registro è l’unico posto in cui la differenza appare. Leggetelo prima di fidarvi del file.

Aggiornate la disposizione, non la riga

Prendete il profilo mantenuto dall’operatore invece di assemblare nomi di algoritmi finché l’importazione smette di lamentarsi. Aggiungere righe per tentativi inverte la direzione della correzione. Adatta il client a un server sconosciuto invece di stabilire cosa supporta il server.

Anche il server potrebbe aver bisogno dell’aggiornamento coordinato. Un client attuale non può creare supporto per una proposta che l’altra estremità non offre mai. Nessuna opzione lato client sostituisce un gateway che non è stato aggiornato.

Ciò che non va sacrificato è la verifica. Rimuovere i controlli dei certificati, disattivare il controllo del nome host o spegnere gli aggiornamenti per tenere in vita un vecchio profilo trasforma un problema di compatibilità in un problema di fiducia. Di solito accade una piccola modifica alla volta.

Confermate il risultato e registrate l’eccezione

Dopo la modifica, ispezionate di nuovo la suite negoziata e provate la risorsa per cui il tunnel esiste. Un profilo che negozia ciò che volevate e non raggiunge comunque il servizio ha un problema di routing o di identità. Non ha un problema crittografico.

Conservate la configurazione precedente nota come buona in un luogo protetto. Un confronto è possibile solo finché il vecchio file esiste ancora.

Documentate ogni eccezione di compatibilità con un responsabile e una data di revisione. Un accordo temporaneo che nessuno possiede diventa una politica permanente. La prossima persona che leggerà il file presumerà che sia stato scelto deliberatamente.