SECLEVEL=0 vindecă simptomul, nu certificatul

O conexiune OpenVPN eșuează, cineva găsește o corecție de o linie care adaugă SECLEVEL=0, și tunelul urcă. Ce s-a schimbat nu a fost certificatul și nici suita de cifrare; s-a mutat un prag de acceptare la nivelul întregii biblioteci, și tot ce face procesul după aceea moștenește noua graniță. Merită înțeles înainte ca aceeași linie să fie copiată în fiecare profil din mediu.

Stabiliți ce bibliotecă și ce politică sunt în vigoare

SECLEVEL este un concept OpenSSL, deci prima întrebare este dacă build-ul dvs. folosește OpenSSL. OpenVPN poate fi legat de mai mult de o bibliotecă criptografică, iar o setare care se aplică uneia dintre ele este lipsită de sens pentru celelalte. Întrebați binarul cu ce a fost construit, apoi întrebați biblioteca ce versiune și configurație a încărcat:

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

Citiți cu atenție rezultatul versiunii, pentru că distribuțiile modifică valorile implicite. Unele livrează o configurație de sistem care ridică nivelul minim peste valoarea implicită din upstream, și de aceea același profil se comportă diferit pe două mașini cu pachete OpenVPN identice. Politica efectivă este cea încărcată de procesul aflat în execuție, nu cea din manualul upstream.

Apoi separați cele două straturi pe care oamenii le confundă. OpenVPN are propriile controale TLS, inclusiv o setare de profil al certificatului și liste explicite de cifruri, iar acestea stau deasupra a tot ce impune biblioteca. Coborârea nivelului bibliotecii nu schimbă ce cifruri enumeră configurația dvs. OpenVPN, iar îngustarea listei OpenVPN nu ridică pragul bibliotecii. Să știți care strat v-a respins este ce împiedică remedierea să rămână o presupunere.

Separați cele trei lucruri care pot fi respinse

Primul candidat este materialul de identitate: un certificat a cărui cheie este prea mică sau al cărui algoritm de semnătură nu mai este acceptat de politică. Al doilea este un parametru de schimb de chei, cum ar fi un grup pe care politica îl consideră prea slab. Al treilea este o suită de cifrare pe care politica o exclude. Toate trei pot produce o eroare de handshake, și doar textul erorii și etapa de negociere le disting.

Niciunul dintre acestea trei nu este cifrul canalului de date. OpenVPN negociază criptarea tunelului separat de handshake-ul TLS, deci o conexiune care reușește după o schimbare de nivel de securitate nu spune nimic despre ce cifru vă protejează datele. Dacă întrebarea pe care o puneți de fapt este despre confidențialitatea datelor, vă uitați la butonul complet greșit.

Coborârea nivelului lărgește acceptarea pentru toate cele trei intrări deodată. Aceasta este partea pe care oamenii o ratează: remedierea care admite un certificat vechi admite și un grup slab și o suită pe care poate nu intenționați să o permiteți. O singură eroare a declanșat schimbarea, iar schimbarea este mai largă decât eroarea. Această asimetrie este motivul pentru care o excepție delimitată este mai bună decât o valoare implicită pentru întregul mediu.

Schimbați intrarea, nu pragul

Păstrați eroarea exactă înainte de a atinge configurația, inclusiv etapa care a raportat-o și obiectul pe care l-a numit. O problemă de certificat se rezolvă înlocuind certificatul cu ceva ce politica actuală acceptă, ceea ce de obicei înseamnă reemiterea lui la autoritate, nu reinstalarea aceluiași fișier.

Dacă intrarea respinsă aparține unui peer pe care nu îl controlați, conversația este cu proprietarul acestuia despre material de înlocuire acceptat. Coborârea propriului prag pentru a găzdui un sistem pe care nimeni nu îl întreține mută costul de la ei la toți cei care se conectează după ei.

Acolo unde serverul aplică politica, verificați dacă o setare la nivel OpenVPN este cauza reală înainte de a da vina pe bibliotecă. Un profil de certificat care cere o clasă mai strictă decât poate satisface certificatul implementat va eșua indiferent de nivelul de securitate, iar eliminarea acelui profil este o schimbare mai îngustă decât dezactivarea verificărilor bibliotecii.

Dacă trebuie să îl coborâți, delimitați-l și documentați-l

Uneori o excepție de compatibilitate aprobată este răspunsul corect, mai ales pentru un peer vechi cu un plan de retragere datat. Limitați-o la serviciul care are nevoie de ea în loc de întregul host: un fișier de configurare pe serviciu sau o configurație OpenSSL dedicată are o rază de impact mai mică decât un export în profilul global.

Notați patru lucruri împreună cu excepția: setarea exactă, proprietarul care a aprobat-o, clienții afectați și condiția în care este eliminată. O excepție fără condiție de retragere este o slăbire permanentă cu o justificare temporară atașată.

Revenirea ar trebui să fie un singur pas pe care l-ați testat deja. Păstrați configurația anterioară, aplicați schimbarea, confirmați că serviciul pornește și știți exact ce fișier să restaurați dacă următoarea conexiune se comportă altfel decât era de așteptat.

Verificați identitatea și protecția după aceea

O conexiune reușită dovedește doar că condițiile revizuite au admis-o. Confirmați că verificarea numelui de host și a peer-ului își face în continuare treaba, că certificatul folosit este cel pe care intenționați să îl implementați și că canalul de date negociat corespunde politicii pe care credeți că o aveți.

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

Referința OpenSSL pentru nivelurile de securitate spune explicit că framework-ul aplică limite cheilor, semnăturilor, grupurilor și suitelor împreună, și că nivelul zero permite tot ce verifică callback-ul. Acesta este domeniul a ceea ce ați schimbat, și aceasta este propoziția de citat când cineva întreabă dacă remedierea a fost îngustă.

Predarea care trece un audit spune ce politică a respins ce intrare, ce s-a schimbat și ce rămâne acceptat ca rezultat. „Funcționează cu SECLEVEL=0“ este o observație despre o conexiune, nu o evaluare de securitate a implementării.