Quali pacchetti OpenVPN protegge il digest di auth?
L'opzione auth copre meno di quanto suggerisca un profilo. Ripercorri il canale, il caso AEAD e la protezione del canale di controllo prima di fissare una politica di digest.
La maggior parte dei dibattiti sui digest OpenVPN parte dal pacchetto sbagliato. Leggere auth SHA256 come «accetta solo peer che offrono SHA256» è la prima cosa da disimparare. L'opzione nomina un digest per pacchetti specifici, e quali siano quei pacchetti dipende dal canale e dal fatto che quel canale sia AEAD. Esamina le quattro domande qui sotto in ordine; ciascuna restringe ciò che l'impostazione può significare nella tua distribuzione.
Nomina il canale che l'impostazione deve proteggere
OpenVPN ha un canale di controllo che trasporta il traffico della stretta di mano TLS e un canale dati che trasporta il carico del tunnel. Il digest auth ha un ruolo in entrambi, ma non lo stesso, e il profilo raramente rende visibile la differenza. Annota quale dei due stai cercando di limitare prima di toccare un file di configurazione.
La tabella qui sotto è la versione breve di come la stessa opzione arriva in ogni contesto.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Verifica se il canale dati è AEAD prima di farci affidamento
Se il cifrario dati negoziato è AES-GCM o CHACHA20-POLY1305, il canale dati autentica se stesso e il digest separato non svolge il lavoro che forse immagini. Entrambi sono costruzioni AEAD, quindi l'integrità è prodotta dalla stessa operazione che cifra il carico. Non è un degrado, ma significa che una politica giustificata come «ogni pacchetto dati è HMAC-SHA256» è di fatto errata su quel tunnel. Conferma il valore negoziato nel registro del server o nell'output di stato del client prima di riscrivere la politica.
Ispeziona il cifrario realmente negoziato invece dell'elenco nel profilo, perché la negoziazione può ricadere su un altro membro dell'insieme. data-ciphers AES-256-GCM:AES-128-GCM è un elenco di negoziazione, e entrambe le voci sono AEAD, quindi nessuna delle due consuma il digest auth per la protezione del carico.
Tratta la protezione del canale di controllo come una decisione a sé
tls-auth aggiunge un HMAC ai pacchetti del canale di controllo e prende il suo digest dall'impostazione auth, per questo un tunnel AEAD può comunque avere un digest significativo configurato. tls-crypt è un'altra disposizione con la propria protezione fissa, quindi non presumere che erediti ogni proprietà di tls-auth. Leggi la documentazione del meccanismo che hai scelto invece di trasferire ipotesi tra i due.
I due peer devono anche essere d'accordo sulla disposizione e sulla direzione della chiave. Un digest che corrisponde ma un file di chiave usato nella direzione sbagliata produce una stretta di mano che fallisce per ragioni che l'impostazione del digest non può spiegare.
Tieni auth separato dalla negoziazione dei cifrari e dai certificati
Tre impostazioni vengono continuamente confuse: il digest auth, l'elenco dei cifrari dati e l'algoritmo di firma del certificato. Cambiare la prima non riemette un certificato, non ne seleziona il digest di firma e non crea un metodo utente-password. Le definizioni delle opzioni di protocollo nei sorgenti di OpenVPN 2.6 descrivono ciascuna nella propria sezione, il che ricorda utilmente che sono manopole indipendenti.
Quando un peer rifiuta di connettersi dopo un cambio di digest, la causa è di solito una discrepanza in una delle altre due impostazioni. Leggi entrambe le estremità prima di cambiare l'una o l'altra.
Scrivi la politica e confrontala con le configurazioni in esecuzione
Una dichiarazione a livello di flotta dovrebbe nominare esplicitamente le modalità di canale dati consentite e la protezione del canale di controllo scelta, nella stessa frase. Quella frase è verificabile; «usiamo SHA256» non lo è. Poi confrontala con i profili effettivi di server e client invece che con un modello in un repository.
Concludi registrando cosa ha realmente negoziato ogni tunnel e quale meccanismo ha autenticato i suoi pacchetti. Una riga auth visibile in un profilo è solo prova dell'intenzione di configurazione, e l'intenzione è la parte più economica del controllo.