SECLEVEL=0 cura el símptoma, no el certificat

Una connexió OpenVPN falla, algú troba una solució d'una línia que afegeix SECLEVEL=0 i el túnel s'aixeca. El que va canviar no va ser el certificat ni el conjunt de xifratges; es va moure un llindar d'acceptació a nivell de biblioteca, i tot el que el procés fa després hereta la nova frontera. Val la pena entendre-ho abans que la mateixa línia es copiï a tots els perfils de l'entorn.

Determineu quina biblioteca i quina política estan en vigor

SECLEVEL és un concepte d'OpenSSL, així que la primera pregunta és si la vostra compilació fa servir OpenSSL. OpenVPN es pot enllaçar amb més d'una biblioteca criptogràfica, i un paràmetre que s'aplica a una d'elles no té sentit per a les altres. Pregunteu al binari amb què es va construir i després pregunteu a la biblioteca quina versió i configuració ha carregat:

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

Llegiu la sortida de la versió amb atenció, perquè les distribucions pedaçen els valors per defecte. Algunes inclouen una configuració del sistema que eleva el nivell mínim per sobre del valor per defecte d'upstream, i per això el mateix perfil es comporta de manera diferent en dues màquines amb paquets OpenVPN idèntics. La política efectiva és la que ha carregat el procés en execució, no la del manual d'upstream.

Després separeu les dues capes que la gent confon. OpenVPN té els seus propis controls TLS, com ara un paràmetre de perfil de certificat i llistes de xifratges explícites, i aquests se situen per sobre del que imposa la biblioteca. Baixar el nivell de la biblioteca no canvia quins xifratges llista la vostra configuració d'OpenVPN, i estrènyer la llista d'OpenVPN no eleva el llindar de la biblioteca. Saber quina capa us ha rebutjat és el que evita que la solució sigui una endevinalla.

Separeu les tres coses que es poden rebutjar

El primer candidat és material d'identitat: un certificat la clau del qual és massa petita o l'algoritme de signatura del qual la política ja no accepta. El segon és un paràmetre d'intercanvi de claus, com un grup que la política considera massa feble. El tercer és un conjunt de xifratges que la política exclou. Els tres poden produir un error de handshake, i només el text de l'error i l'etapa de negociació els distingeixen.

Cap d'aquests tres és el xifratge del canal de dades. OpenVPN negocia el xifratge del túnel per separat del handshake TLS, així que una connexió que té èxit després d'un canvi de nivell de seguretat no diu res sobre quin xifratge protegeix la vostra càrrega. Si la pregunta que feu en realitat és sobre la confidencialitat de les dades, esteu mirant el dial equivocat.

Baixar el nivell amplia l'acceptació per a les tres entrades alhora. Aquesta és la part que la gent passa per alt: la solució que admet un certificat antic també admet un grup feble i un conjunt que potser no teníeu intenció de permetre. Un sol error va provocar el canvi, i el canvi és més ampli que l'error. Aquesta asimetria és la raó per la qual una excepció acotada és millor que un valor per defecte per a tot l'entorn.

Canvieu l'entrada, no el llindar

Conserveu l'error exacte abans de tocar la configuració, inclosa l'etapa que el va reportar i l'objecte que va nomenar. Un problema de certificat es resol substituint el certificat per alguna cosa que l'actual política accepti, cosa que normalment vol dir reemetre'l a l'autoritat en lloc de reinstal·lar el mateix fitxer.

Si l'entrada rebutjada pertany a un parell que no controleu, la conversa és amb el propietari d'aquest parell sobre material de substitució admès. Baixar el vostre propi llindar per acomodar un sistema que ningú manté trasllada el cost d'ells a tots els que es connecten després.

On el servidor aplica la política, comproveu si un paràmetre a nivell d'OpenVPN n'és la causa real abans de culpar la biblioteca. Un perfil de certificat que demana una classe més estricta que la que el certificat desplegat pot satisfer fallarà sigui quin sigui el nivell de seguretat, i eliminar aquest perfil és un canvi més estret que desactivar les comprovacions de la biblioteca.

Si l'heu de baixar, acoteu-lo i documenteu-lo

De vegades una excepció de compatibilitat aprovada és la resposta correcta, sobretot per a un parell antic amb un pla de retirada datat. Acoteu-la al servei que la necessita en lloc de tot l'amfitrió: un fitxer de configuració per servei o una configuració OpenSSL dedicada té un radi d'impacte més petit que una exportació al perfil global.

Anoteu quatre coses amb l'excepció: el paràmetre exacte, el propietari que l'ha aprovat, els clients afectats i la condició sota la qual es retira. Una excepció sense condició de retirada és un debilitament permanent amb una justificació temporal adjunta.

La reversió hauria de ser un sol pas que ja heu provat. Conserveu la configuració anterior, apliqueu el canvi, confirmeu que el servei arrenca i sapigueu exactament quin fitxer restaurar si la propera connexió es comporta diferent del que esperàveu.

Verifiqueu la identitat i la protecció després

Una connexió correcta només demostra que les condicions revisades l'han admesa. Confirmeu que la verificació del nom d'amfitrió i del parell encara fa la seva feina, que el certificat en ús és el que volíeu desplegar i que el canal de dades negociat coincideix amb la política que creieu tenir.

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

La referència dels nivells de seguretat d'OpenSSL és explícita que el marc aplica límits a claus, signatures, grups i conjunts alhora, i que el nivell zero permet tot el que comprova la crida de tornada. Aquest és l'abast del que heu canviat, i és la frase que cal citar quan algú pregunta si la solució era estreta.

El traspàs que sobreviu a una auditoria diu quina política va rebutjar quina entrada, què es va canviar i què continua acceptat com a resultat. «Funciona amb SECLEVEL=0» és una observació sobre una connexió, no una avaluació de seguretat del desplegament.