Log OpenVPN: cifratura del canale di controllo contro cifratura del canale dati

Una riga di log che nomina DHE-RSA-AES256-SHA non è un riepilogo dell’intera connessione. Appartiene all’handshake TLS che protegge il canale di controllo, e il traffico dentro il tunnel può essere cifrato in modo del tutto diverso. Presentarla come cifratura dati della VPN è l’errore da evitare.

Contano due risultati, e rispondono a domande diverse. Uno è la suite TLS negoziata per il canale di controllo; l’altro è la cifratura dati per i pacchetti che il tunnel trasporta.

Due risultati, due domande

Il canale di controllo trasporta l’handshake e i messaggi di gestione tra i peer. La sua cifratura è scelta dallo stack TLS, quindi il nome segue le convenzioni TLS. Il canale dati trasporta il traffico utente ed è configurato dalla negoziazione della cifratura propria di OpenVPN.

Decidi a quale domanda stai rispondendo prima di leggere l’una o l’altra riga. Se il tunnel è cifrato e se l’handshake è solido non sono la stessa domanda.

Un estratto di log che mostra entrambe le righe è quello utile. Leggi la riga di controllo per la versione e la suite TLS, e la riga dati per l’algoritmo che protegge davvero il payload.

Decodifica il nome della suite TLS nel suo contesto

In un nome storico in stile OpenSSL come DHE-RSA-AES256-SHA, ogni componente descrive una decisione diversa. DHE è lo scambio di chiavi Diffie-Hellman effimero, RSA è il metodo di autenticazione, AES256 è AES-256 in modalità CBC per i record TLS, e SHA è il MAC dei record basato su SHA-1.

L’ultimo componente non è un’impronta del certificato, e leggerlo come tale è un errore comune. Il nome non indica nemmeno la versione del protocollo da solo, perché TLS 1.3 usa uno schema di denominazione del tutto diverso. TLS_AES_256_GCM_SHA384 segue quella forma più recente, in cui l’hash finale fa parte della costruzione della suite anziché essere una scelta di MAC. Applica la lettura per componenti solo allo stile di denominazione più vecchio.

La guida alle suite OpenSSL collega questi nomi alle loro definizioni se un componente non è familiare.

Leggi il risultato del canale dati per il traffico trasportato

Per il traffico trasportato, leggi la riga del canale dati della stessa sessione. Un elenco data-ciphers nella configurazione è un insieme consentito, non la prova che un particolare algoritmo sia stato negoziato. Il log registra la scelta; la configurazione elenca il menu.

Una cifratura AEAD come AES-GCM porta con sé il proprio controllo di integrità, quindi un HMAC separato per il canale dati non fa parte di quel percorso.

La direttiva auth non aggiorna né TLS né i certificati né la cifratura dati. Seleziona un digest per le parti del protocollo che ne usano ancora uno, e con una cifratura dati AEAD non c’è un HMAC dati separato da configurare.

Tieni i controlli d’identità fuori dal risultato della cifratura

L’algoritmo di firma del certificato, la validazione della catena di fiducia e la verifica del nome del peer sono altre tre proprietà di cui un nome di cifratura non dice nulla. Un certificato scaduto fallisce, per quanto solida sia la suite. Un nome server non corrispondente fallisce allo stesso modo. Correggere un’impostazione di digest nel profilo non ripara né l’uno né l’altro.

Tieni questi controlli nelle note di revisione accanto al risultato della cifratura, non fusi in esso.

Registra i risultati negoziati della sessione corrente

Prendi i risultati della connessione corrente e registra insieme le versioni del client e del server. Un log in sola aggiunta può contenere la riga di una sessione più vecchia, e citarla come attuale è il modo in cui un problema risolto sembra persistere.

Per una revisione delle politiche, consegna al responsabile della configurazione la versione e la suite TLS negoziate, la cifratura dati scelta e le impostazioni di validazione dei certificati insieme. Modifica quel livello, poi leggi un log nuovo per confermare i nuovi valori negoziati.