SECLEVEL=0 cura il sintomo, non il certificato

Una connessione OpenVPN fallisce, qualcuno trova una correzione di una riga che aggiunge SECLEVEL=0 e il tunnel sale. Ciò che è cambiato non è stato il certificato né la suite di cifratura; si è spostata una soglia di accettazione a livello di libreria, e tutto ciò che il processo fa dopo eredita il nuovo confine. Vale la pena capirlo prima che la stessa riga venga copiata in ogni profilo del parco.

Stabilite quale libreria e quale criterio sono in vigore

SECLEVEL è un concetto di OpenSSL, quindi la prima domanda è se la vostra build usi OpenSSL. OpenVPN può essere collegato a più di una libreria crittografica, e un'impostazione che vale per una di esse è priva di senso per le altre. Chiedete al binario con cosa è stato costruito, poi chiedete alla libreria quale versione e configurazione ha caricato:

openvpn --version | head -3
openssl version -a

Leggete l'output della versione con attenzione, perché le distribuzioni modificano i valori predefiniti. Alcune forniscono una configurazione di sistema che alza il livello minimo sopra il valore predefinito di upstream, ed è per questo che lo stesso profilo si comporta diversamente su due macchine con pacchetti OpenVPN identici. Il criterio effettivo è quello caricato dal processo in esecuzione, non quello del manuale di upstream.

Poi separate i due livelli che le persone confondono. OpenVPN ha i propri controlli TLS, tra cui un'impostazione del profilo del certificato e liste di cifrature esplicite, e questi si collocano sopra tutto ciò che la libreria impone. Abbassare il livello della libreria non cambia quali cifrature elenca la vostra configurazione OpenVPN, e restringere la lista OpenVPN non alza la soglia della libreria. Sapere quale livello vi ha rifiutato è ciò che impedisce alla correzione di restare un'ipotesi.

Separate le tre cose che possono essere rifiutate

Il primo candidato è il materiale di identità: un certificato la cui chiave è troppo piccola o il cui algoritmo di firma non è più accettato dal criterio. Il secondo è un parametro di scambio chiavi, come un gruppo che il criterio ritiene troppo debole. Il terzo è una suite di cifratura esclusa dal criterio. Tutti e tre possono produrre un errore di handshake, e solo il testo dell'errore e la fase di negoziazione li distinguono.

Nessuno di questi tre è la cifratura del canale dati. OpenVPN negozia la cifratura del tunnel separatamente dall'handshake TLS, quindi una connessione che riesce dopo un cambio di livello di sicurezza non dice nulla su quale cifratura protegga i vostri dati. Se la domanda che state davvero ponendo riguarda la riservatezza dei dati, state guardando completamente la manopola sbagliata.

Abbassare il livello amplia l'accettazione di tutti e tre gli input insieme. È la parte che le persone perdono: la correzione che ammette un vecchio certificato ammette anche un gruppo debole e una suite che forse non intendevate permettere. Un solo errore ha provocato il cambiamento, e il cambiamento è più ampio dell'errore. Questa asimmetria è il motivo per cui un'eccezione circoscritta è meglio di un valore predefinito per tutto il parco.

Cambiate l'input, non la soglia

Conservate l'errore esatto prima di toccare la configurazione, compresa la fase che l'ha segnalato e l'oggetto che ha nominato. Un problema di certificato si risolve sostituendo il certificato con qualcosa che il criterio attuale accetta, il che di solito significa riemetterlo presso l'autorità invece di reinstallare lo stesso file.

Se l'input rifiutato appartiene a un peer che non controllate, la conversazione è con il suo proprietario sul materiale sostitutivo supportato. Abbassare la vostra soglia per accogliere un sistema che nessuno mantiene sposta il costo da loro a tutti quelli che si collegano dopo.

Dove il server applica il criterio, verificate se sia un'impostazione a livello OpenVPN la causa reale prima di incolpare la libreria. Un profilo del certificato che richiede una classe più severa di quella che il certificato distribuito può soddisfare fallirà qualunque sia il livello di sicurezza, e rimuovere quel profilo è un cambiamento più stretto che disattivare i controlli della libreria.

Se dovete abbassarlo, circoscrivetelo e documentatelo

A volte un'eccezione di compatibilità approvata è la risposta giusta, soprattutto per un peer legacy con un piano di dismissione datato. Limitatela al servizio che ne ha bisogno invece che all'intero host: un file di configurazione per servizio o una configurazione OpenSSL dedicata ha un raggio d'impatto più piccolo di un'esportazione nel profilo globale.

Annotate quattro cose con l'eccezione: l'impostazione esatta, il proprietario che l'ha approvata, i client interessati e la condizione alla quale verrà rimossa. Un'eccezione senza condizione di dismissione è un indebolimento permanente con una giustificazione temporanea allegata.

Il rollback dovrebbe essere un solo passo che avete già testato. Conservate la configurazione precedente, applicate il cambiamento, confermate che il servizio si avvia e sappiate esattamente quale file ripristinare se la connessione successiva si comporta diversamente dal previsto.

Verificate identità e protezione in seguito

Una connessione riuscita dimostra solo che le condizioni riviste l'hanno ammessa. Confermate che la verifica del nome host e del peer faccia ancora il suo lavoro, che il certificato in uso sia quello che intendevate distribuire e che il canale dati negoziato corrisponda al criterio che credete di avere.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

Il riferimento ai livelli di sicurezza di OpenSSL è esplicito sul fatto che il framework applica limiti a chiavi, firme, gruppi e suite insieme, e che il livello zero permette tutto ciò che il callback controlla. Questa è la portata di ciò che avete cambiato, ed è la frase da citare quando qualcuno chiede se la correzione era stretta.

Il passaggio di consegne che supera un audit dice quale criterio ha rifiutato quale input, cosa è stato cambiato e cosa resta accettato di conseguenza. «Funziona con SECLEVEL=0» è un'osservazione su una connessione, non una valutazione di sicurezza della distribuzione.