Tracciare i pacchetti di controllo OpenVPN: tls-auth prima di TLS

Un errore tls-auth viene di solito segnalato come problema di handshake, e non lo è mai stato. L’HMAC viene controllato sul pacchetto di controllo prima che avvenga qualsiasi elaborazione TLS, quindi una chiave o una direzione errata produce un errore che sembra un problema di certificato e viene deciso due livelli prima. Trattare la busta come un oggetto a sé rende breve la diagnosi: leggete i campi, confermate che il controllo scatta presto, poi confrontate le tre cose su cui entrambe le estremità devono concordare.

Leggete la busta nell’ordine in cui viene costruita

Un pacchetto di controllo trasporta un identificatore di sessione, l’HMAC tls-auth opzionale, informazioni di ripetizione e conferma, e un identificatore di messaggio affidabile, poi segue il carico utile del tipo di messaggio. Quando il messaggio è un messaggio di handshake, il carico utile è per l’appunto testo cifrato TLS. È tutta qui la relazione: il materiale TLS viaggia dentro un messaggio che la busta già protegge. La referenza del protocollo di rete di OpenVPN elenca i campi del canale di controllo in quest’ordine.

Lo strato di affidabilità si confonde facilmente con la crittografia. Le conferme, la ritrasmissione e l’identificatore di messaggio esistono perché i messaggi di controllo arrivino una volta e in ordine su un trasporto inaffidabile. Non sono autenticazione, e un identificatore di messaggio corretto non prova nulla su chi ha inviato il pacchetto.

Mantenete questo raggruppamento concettuale. Non è uno schema dell’ordine dei byte e non basta a calcolare un tag, perché i campi che entrano nell’HMAC dipendono da implementazione, versione e modalità.

Dimostrate che il controllo scatta prima dell’handshake

Un ricevitore che possiede la chiave condivisa può verificare l’HMAC e scartare subito un pacchetto falsificato, senza allocare stato di handshake né svolgere lavoro con chiave pubblica. La protezione copre anche i pacchetti iniziali dell’handshake, ed è proprio per questo che una chiave sbagliata si presenta come connessione fallita e non come errore di autenticazione tardivo.

Aumentate la verbosità del demone e osservate il canale di controllo invece del dispositivo tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Quello che cercate è un errore di verifica HMAC del canale di controllo segnalato a livello di pacchetto, prima di qualsiasi avviso TLS. Un avviso TLS nel registro significa che la busta è stata accettata e l’errore si è spostato verso l’interno, che è un’altra indagine con un’altra soluzione.

Anche la gestione della direzione sta qui. Quando si usa un file di chiave statica con tls-auth, le due estremità assumono direzioni di chiave opposte, e il protocollo usa questa separazione perché un pacchetto catturato non possa essere riflesso al mittente. Invertire la direzione lascia la chiave identica e fa comunque fallire ogni pacchetto. Cambiate un’estremità alla volta, poi riavviate entrambi i demoni perché la coppia sia caricata insieme.

Allineate chiave, direzione e digest su entrambe le estremità

Tre valori devono concordare e solo uno di essi è il file. Il contenuto della chiave statica deve essere identico su entrambe le estremità, la direzione deve essere opposta e il digest usato per l’HMAC deve corrispondere. Controllate la configurazione prima di toccare il materiale della chiave, perché una sola direzione invertita spiega più errori di un file corrotto:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Generate il segreto condiviso con lo strumento e non con un editor, e mantenete i permessi stretti:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Le versioni precedenti accettavano un ordine di opzioni leggermente diverso per la generazione delle chiavi, e i profili scritti per quelle versioni circolano ancora. Il file generato è lo stesso tipo di oggetto in entrambi i casi, quindi il controllo è se le due estremità hanno byte identici, non quale grafia li ha prodotti.

Non confondete tls-auth con tls-crypt. Entrambi proteggono il canale di controllo, ma tls-crypt lo cifra anche e nasconde l’handshake agli osservatori, e sostituisce la separazione delle direzioni con la propria gestione delle chiavi. Un profilo che usa uno non interopererà con un peer configurato per l’altro, e nessuna messa a punto del digest chiude quel divario.

Riproducete un tag solo dal formato reale

La riproduzione esatta a livello di byte è un compito separato dall’eseguire una VPN, e funziona solo con gli input reali: l’implementazione e la versione che hanno costruito il pacchetto, il digest scelto, la direzione e i byte effettivi, compresi l’identificatore di sessione e l’array di conferme. Una resa testuale dell’elenco dei campi non è quei byte.

La lunghezza del tag deriva dal digest, quindi l’ipotesi di lunghezza fissa crolla nel momento in cui qualcuno la cambia. Calcolate l’hash del pacchetto come fa l’implementazione, non come lo presenta una tabella in un post di blog, e confrontate con una cattura presa dallo stesso peer invece che con un’aspettativa ricavata a mano.

Tenete quell’esercizio lontano dai profili di produzione. Nulla nella riproduzione di un tag vi dice se un’installazione debba abilitare la protezione.

Annullate una discrepanza senza rimuovere la protezione

Il test tentante è eliminare tls-auth, vedere la connessione riuscire e concludere che la chiave era sbagliata. Quella risposta vi costa la protezione e non insegna nulla su quale dei tre valori fosse discorde. Recuperate invece la configurazione corrispondente approvata dal lato server e confrontate con essa.

Preparate la modifica in modo che sia reversibile. Conservate la configurazione e il file di chiave precedenti del server, applicate la coppia corretta, verificate che un client completi l’handshake, e solo allora rimuovete il backup. Se i client falliscono dopo la modifica, ripristinate i file precedenti invece di improvvisare una terza variante durante un’interruzione. Il ripristino dovrebbe essere un comando che già conoscete prima di iniziare.

Infine, ricordate che cosa significa un controllo superato. Prova che il peer possiede la chiave condivisa, non che il suo certificato o account sia autorizzato, e non dice nulla sulla cifratura negoziata del canale dati. L’autorizzazione e la protezione dei dati vengono stabilite più tardi, quindi un controllo pulito della busta è un punto di partenza e non un verdetto.