OpenVPN tls-ciphersuites contro tls-version-min: cosa impone ciascuno

Tre fatti diversi vengono compressi in una sola riga nella maggior parte delle discussioni OpenVPN su TLS: cosa può fare la tua build client, cosa consente il profilo e cosa ha realmente negoziato la sessione. Un breve elenco di suite TLS 1.3 risponde solo a metà alla domanda centrale e non dice nulla sul limite inferiore della versione del protocollo. Segui i controlli qui sotto in ordine e fermati al primo che non regge, perché ogni controllo successivo presuppone che i precedenti siano risolti.

Controlla la build prima di leggere qualsiasi elenco

Una direttiva di configurazione non può aggiungere a un binario il supporto di un protocollo che non possiede. Inizia dal banner di versione, che nomina la libreria crittografica compilata:

openvpn --version

Una build 2.6 collegata a OpenSSL accetta sia tls-cipher sia tls-ciphersuites. Una build con mbed TLS non ha alcuna selezione di suite TLS 1.3, e il manuale 2.6 contrassegna tls-ciphersuites come opzione OpenSSL. Se il server viene ricompilato con un altro backend, lo stesso profilo può cambiare comportamento senza che cambi una sola riga di configurazione.

Finché sei qui, esegui openvpn --show-tls e conserva l'output. È l'inventario con cui confronterai più avanti, ed è economico catturarlo prima che qualcuno inizi a modificare i profili.

Scrivi il banner e l'elenco nel ticket di modifica, non in una finestra di chat. Quando due persone discutono se un client potrà offrire una suite tra sei settimane, l'output catturato lo risolve in una riga.

Tieni i limiti di versione separati dagli elenchi di cifrari

Nel manuale 2.6 questi sono tre controlli, non uno:

• tls-cipher imposta la politica dei cifrari per TLS 1.2 e precedenti, e viene passato all'elenco dei cifrari di OpenSSL;
• tls-ciphersuites seleziona le suite TLS 1.3;
• tls-version-min e tls-version-max delimitano le versioni di protocollo che la connessione può usare.

Quindi un elenco di suite TLS 1.3 accuratamente potenziato non dimostra nulla sul fatto che una versione più vecchia sia ancora consentita. Se il requisito è «solo TLS 1.3», è il limite inferiore di versione a sostenerlo, e l'elenco di suite si limita a restringere le scelte dentro quel limite:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Quella coppia svolge due compiti. Eliminare una delle righe lascia l'altra a imporre meno di quanto pensi, ed è esattamente il guasto che tutto questo controllo esiste per intercettare.

Il canale dati è un quarto controllo. data-ciphers negozia il cifrario simmetrico dentro il tunnel, e il suo risultato non dice nulla sulla versione TLS del canale di controllo. Vedere AES-256-GCM nel riepilogo della sessione non è prova di TLS 1.3 in nessuna direzione.

Leggi show-tls come inventario locale

--show-tls elenca le suite supportate dalla libreria crittografica a cui questo binario è collegato, in ordine di preferenza. Non è un resoconto del gateway. Il manuale dice esplicitamente che l'elenco proviene dalla libreria locale, il che significa che un portatile con OpenSSL 3.x e un router con una build più vecchia stamperanno elenchi diversi mentre parlano con lo stesso server.

Supponi che un client supporti le suite A, B e C e che una sessione scelga B. Ciò non stabilisce nulla sul fatto che il server consenta A o C, né sul fatto che B sia la sua unica scelta consentita. Tieni separate le tre righe, e la maggior parte dei thread TLS confusi si risolverà da sola.

L'inventario vale comunque la pena conservarlo. Quando una sessione fallisce, confrontare l'elenco della libreria con quello del profilo ti dice se il client avesse qualche possibilità di offrire ciò che il server voleva. Mostra anche se un cambiamento di backend ha silenziosamente rimosso TLS_CHACHA20_POLY1305_SHA256 dal pool su cui contano i client più vecchi — il tipo di regressione che si manifesta come una manciata di utenti che non riescono a connettersi mentre tutti gli altri non notano nulla.

Chiedi al gateway qualcosa a cui può rispondere

Se amministri il servizio, ispeziona la configurazione effettiva dell'istanza in esecuzione anziché un file su disco. OpenVPN potrebbe essere stato avviato con un percorso --config diverso, potrebbe caricare inclusioni e potrebbe non essere stato riavviato dopo la modifica. La politica del demone in esecuzione è quella che i client incontrano.

Se non lo amministri, chiedi all'operatore i requisiti client supportati o un test di accettazione circoscritto. Un tentativo rifiutato non è automaticamente una suite rifiutata: un limite inferiore di versione, controlli di identità del certificato come remote-cert-tls, o un disallineamento tra tls-auth e tls-crypt possono terminare lo scambio prima che la selezione della suite abbia importanza. Leggi l'errore del server prima di cambiare l'elenco del client, perché «handshake failed» copre quattro cause diverse e solo una di esse è un disallineamento di cifrario.

Puntare openssl s_client verso la porta VPN non riproduce nemmeno la domanda. Il canale di controllo gira dentro l'incapsulamento proprio di OpenVPN, quindi una sonda TLS grezza testa un protocollo diverso su una porta che si aspetta qualcos'altro. Qualsiasi conclusione tratta da essa riguarda la sonda, non il tunnel.

Registra due risultati e mantienili separati

Una sessione consentita appena aperta produce una riga del canale di controllo che nomina la versione del protocollo e il cifrario selezionato, e una riga separata del canale dati che nomina il cifrario del tunnel. Cattura entrambe con la versione del client e il nome del profilo, e annota quale istanza del server ha risposto:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Poi leggi le due righe da quel file invece che dalla memoria. La coppia è la prova; un nome di suite da solo è una preferenza, e il limite di versione è un'affermazione separata su ciò che il server rifiuta.

Esegui i controlli in questo ordine. Conferma la build e il backend con --version. Cattura --show-tls prima di cambiare qualsiasi cosa. Enuncia il limite inferiore di versione richiesto separatamente dall'elenco delle suite. Conferma la politica effettiva dell'istanza in esecuzione con il suo proprietario. Osserva una sessione consentita e, se il piano lo consente, un tentativo rifiutato con una versione più vecchia. Registra i risultati del canale di controllo e del canale dati come riscontri separati.

Se un client richiesto non può soddisfare un nuovo minimo, prendi quella decisione di migrazione o eccezione esplicitamente invece di abbassare in silenzio una regola di accettazione non correlata per far sembrare concluso il rollout.