Un vecchio peer impone TLS 1.0: limitare l’eccezione, non l’host

Compare un vecchio dispositivo, non riesce a connettersi, e la riparazione che sembra più rapida è indebolire l’intero host finché la connessione non riesce. Quello scambio è invisibile sul momento e permanente nella pratica, perché nessuno rimuove un livello minimo che finalmente funziona. Due guasti molto diversi creano la pressione, e solo uno dei due riguarda davvero i cifrari. Classifica prima il guasto, poi colloca l’eccezione dove non può propagarsi.

Dividere il guasto in due prima di modificare una direttiva

Una riga di log del server su nessun cifrario condiviso, o su una versione di protocollo non supportata, proviene dal canale di controllo: le due estremità non sono riuscite a concordare come proteggere la negoziazione stessa. Una riga del client che dice che nessun metodo di verifica del certificato server è abilitato proviene da tutt’altro luogo, perché quel client non sta affatto controllando chi ha risposto. Cambiare un cifrario dati non serve al secondo caso, e aggiungere un controllo di ruolo non serve al primo.

Prendi la prima riga di errore di ciascuna parte, non l’ultima prima della disconnessione, perché l’ultima è di solito una conseguenza. Stabilisci poi quale file il client ha davvero aperto: un profilo importato esiste spesso due volte con nomi visualizzati diversi, e modificare la copia che nessuno legge produce un’assenza di cambiamento convincente. Un processo in esecuzione conserva le impostazioni con cui è partito, quindi un file salvato non è un file caricato. I comandi qui sotto mostrano la negoziazione del client accanto alla vista del server sullo stesso tentativo.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Un secondo listener è il posto onesto per un livello minimo più debole

Quando il dispositivo arriva al massimo a TLS 1.0 con un canale dati pre-2.5, il server deve offrire un livello minimo più basso per il canale di controllo e un cifrario dati che il vecchio client riconosca. La direttiva di fallback esiste proprio per quel peer, mentre l’elenco dei cifrari mantiene i client moderni su suite moderne. Entrambe le direttive appartengono al listener e non a un utente o a una connessione, e nessuna opzione per singolo client le restringe in seguito. Ecco perché un dispositivo legacy sulla porta principale è una decisione che riguarda ogni peer che la condivide.

Dove la piattaforma lo consente, esegui il listener legacy come istanza separata su una porta dedicata, consenti quella porta solo dall’indirizzo del dispositivo e lascia in pace il servizio principale. Scrivi perché esiste il secondo listener, nel file che ne contiene la configurazione, perché altrimenti una futura pulizia lo leggerà come residuo. La separazione vale solo se il livello minimo più debole finisce dove finisce il dispositivo.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Che cosa rompe davvero un vecchio certificato del provider

L’errore di verifica è un binding di ruolo mancante: senza di esso il client accetta qualsiasi certificato che risalga a una CA fidata, che sia stato emesso per un server o no. Associa prima il certificato al ruolo server, e tratta l’associazione come un requisito invece che come una manopola di regolazione. Solo un profilo che fallisce ancora dopo quel passaggio ha un vero problema di certificato.

Un vecchio certificato del provider la cui dimensione della chiave o il cui algoritmo di firma non soddisfa più la policy OpenSSL predefinita è il caso di una modifica mirata del livello di sicurezza sul canale di controllo. Abbassare il livello lì non disattiva la verifica, e non va mai combinato con una CA vuota, una verifica disabilitata o un hostname non controllato. Tieni la riga dentro l’unico profilo che ne ha bisogno; esportare globalmente una configurazione OpenSSL allentata darebbe lo stesso allentamento a ogni programma della macchina.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Leggere i valori negoziati, non il banner

Con verbosità 4 entrambe le estremità stampano la versione TLS e il cifrario del canale di controllo su cui si sono accordate, e il cifrario dati della sessione. Leggi quelle righe invece del banner di inizializzazione, che riporta un successo e non i suoi termini. Poi riconnetti un client moderno al listener principale e conferma che approdi ancora a una suite moderna, perché un’eccezione che è filtrata nella configurazione condivisa si vede qui per prima. I valori che copi diventano la base per la prossima revisione.

Prova il vecchio dispositivo da solo: deve connettersi, e deve essere l’unica sessione nei log che mostra i parametri più deboli. Se anche un secondo peer negozia la vecchia suite, l’eccezione è più ampia del previsto e la separazione dei listener non è davvero avvenuta. Registra entrambe le osservazioni, non solo la conclusione.

Ogni eccezione ha bisogno di un proprietario e di una data

Un’eccezione senza condizione di rimozione diventa silenziosamente la regola, quindi metti il dispositivo, il proprietario, il motivo e la data in cui sparisce accanto alla configurazione che giustifica. Senza quella riga il livello minimo più debole sopravvive all’hardware che ne aveva bisogno.

Sostituire il client, o chiedere al provider un profilo aggiornato, è il risultato da perseguire; l’eccezione è un rinvio e non un progetto. Quando il dispositivo viene ritirato, rimuovi il listener e il profilo nella stessa modifica, così nessuna delle due metà continua a girare. Nulla di tutto questo rende sicuri i vecchi parametri: impedisce solo che il limite di un dispositivo diventi la base di tutti.