OpenVPN tls-crypt-v2: cosa fanno la chiave client e il blob incapsulato

Incollare un profilo tls-crypt-v2 in un ticket sembra innocuo finché non si conta cosa contiene il file. La chiave del canale di controllo del client sta accanto a una copia cifrata della stessa chiave, e un terzo oggetto, la chiave di incapsulamento, non lascia mai il server che accetta. Questi tre rispondono a domande diverse su custodia, condivisione e dismissione. Separarli risolve la maggior parte delle discussioni di policy prima che inizino.

Cosa contiene davvero il profilo

La metà client di tls-crypt-v2 è una chiave più una copia incapsulata. Il client usa la chiave in chiaro per proteggere il canale di controllo e consegna la copia incapsulata al server durante la configurazione, così il server recupera la stessa chiave senza conservare una copia in chiaro per client. La chiave di incapsulamento rende possibile quel recupero e appartiene solo al lato che accetta. Tutto quanto segue deriva da dove vivono questi tre oggetti.

Leggi la tabella per custodia, non per nome, e le conseguenze emergono da sole. Perdere la chiave di incapsulamento è l'evento costoso, perché nulla in un profilo può ricostruirla e il recupero onesto è riemettere il gruppo. Un profilo trapelato costa meno ma è molto più comune, perché le persone incollano i profili nei ticket credendo che la copia incapsulata renda il file sicuro da condividere. I due guasti richiedono risposte diverse, ed è per questo che gli oggetti restano separati.

Perché la copia incapsulata non è tutta la storia

Un profilo porta il materiale client utilizzabile insieme alla sua controparte incapsulata, quindi proteggere la copia per il server non dice nulla sulla protezione del file. Il blob è sicuro da trasmettere e non sicuro da pubblicare. I metadati al suo interno sono visibili a chiunque riceva il blob, compreso chiunque in seguito legga il ticket in cui è stato incollato.

Tratta un profilo come una credenziale, non come un esempio di configurazione. Un file trapelato dà a chi lo detiene un'identità client funzionante finché il server non smette di accettare quell'identità, e l'incapsulamento non fa nulla riguardo a quella finestra. Emetti un profilo per client così la revoca resta una decisione su un singolo file, e salva la chiave di incapsulamento separatamente dalla configurazione del server che abilita. Nessuna delle due abitudini ripara un profilo compromesso, ma entrambe decidono quanto rapidamente verrà contenuto il prossimo.

Dove si colloca l'hook di verifica nell'handshake

L'hook di verifica viene eseguito prima che lo stack TLS sia esposto, e il suo compito è ispezionare i metadati trasportati nel blob incapsulato. Riceve quei metadati più un ambiente piccolo e documentato, e ha meno con cui lavorare rispetto a un hook di autenticazione. Supporre che possa vedere nomi utente, stato della sessione o variabili dei plugin è il modo abituale in cui questo hook viene scritto male. Leggi la sezione del manuale dell'hook stesso invece di prendere in prestito aspettative da un altro hook.

Il suo stato di uscita è la decisione: un risultato diverso da zero rifiuta il client e un risultato zero lascia proseguire l'handshake. La policy deve quindi dire cosa accade quando i metadati mancano, non sono analizzabili o sono inattesi. Scrivi prima il percorso di rifiuto, poi decidi quali valori sono accettabili.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Quelle due righe sono la superficie della policy sul server: una nomina la chiave di incapsulamento, l'altra nomina il programma che giudica ogni client. Tutto l'interessante vive nello script, che merita controllo di versione e la stessa revisione di qualsiasi altra regola di accesso.

Account, certificato e chiave di controllo si dismettono separatamente

L'accettazione anticipata del canale di controllo non è autenticazione, perché avviene prima del controllo dell'identità TLS e prima di qualsiasi autorizzazione dell'account. Disabilitare un account, revocare un certificato e rifiutare una chiave di controllo client sono tre azioni con tre meccanismi. Un'installazione che ne esegue solo una ha una lacuna, non una policy. Riconcilia le tre deliberatamente e registra quale passo esercita quale autorità.

Il tempismo è la seconda distinzione. Un elenco di accettazione modificato vale per i nuovi handshake, mentre le sessioni già stabilite continuano finché qualcosa non le termina. Contare le voci del nuovo elenco come prova che le vecchie sessioni sono finite è il modo in cui un client rimosso resta connesso per ore.

Autorità non riconciliate lasciano due buchi facili da trovare in pratica. Un account può essere disabilitato mentre la sua chiave di controllo apre ancora un handshake, e un certificato può essere revocato mentre la policy dei metadati ammette ancora lo stesso client. Entrambi sono lo stesso errore in luoghi diversi, perché un operatore ha trattato un solo elenco come l'intera autorità. Metti i tre elenchi fianco a fianco al momento della rimozione e l'errore diventa visibile.

Emettere e revocare un profilo

L'emissione è la metà facile: crea la chiave client sul lato che accetta, consegna il profilo a esattamente un proprietario, mantieni limitato il materiale di incapsulamento ed esegui lo stesso programma di verifica su ogni server che accetta. L'ammissione a basso costo è una proprietà dell'intero gruppo, non dell'host più recente. Un secondo server con uno script più vecchio o più lasso diventa silenziosamente il percorso più debole dell'installazione.

La revoca richiede i tre passi in un ordine deliberato. Nega il client nell'hook di verifica così i nuovi handshake falliscono, revoca il suo certificato se si usa una PKI e disabilita l'account così l'autorizzazione successiva non ha nulla da autorizzare. Poi termina le sessioni che la vecchia accettazione permetteva, poiché non noteranno nessuno dei tre. Prova la sequenza su un client che puoi permetterti di rompere.

I metadati in un profilo sono un input per quella policy, non la prova che il controllo degli accessi esista già. Il documento di progettazione di OpenVPN 2.6 descrive gli oggetti e il confine che tracciano, mentre l'applicazione resta all'operatore.