SECLEVEL=0 behandlar symptomet, ikkje sertifikatet

Ei OpenVPN-tilkopling feilar, nokon finn ei retting på éi line som legg til SECLEVEL=0, og tunnelen kjem opp. Det som endra seg, var ikkje sertifikatet og ikkje chifferpakken; ein akseptterskel for heile biblioteket flytta seg, og alt prosessen gjer etterpå arvar den nye grensa. Det er verdt å forstå før den same lina blir kopiert inn i kvar profil i miljøet.

Finn ut kva bibliotek og kva policy som gjeld

SECLEVEL er eit OpenSSL-omgrep, så det første spørsmålet er om bygget ditt brukar OpenSSL i det heile. OpenVPN kan koblast mot meir enn eitt kryptografibibliotek, og ei innstilling som gjeld for eitt av dei, er meiningslaus for dei andre. Spør den binære fila kva ho er bygd med, og spør deretter biblioteket kva versjon og konfigurasjon det lasta:

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

Les versjonsutskrifta nøye, fordi distribusjonar patchar standardverdiar. Nokre leverer ein systemkonfigurasjon som hevar minimumsnivået over upstream-standarden, og difor oppfører den same profilen seg annleis på to maskinar med identiske OpenVPN-pakkar. Den effektive policyen er den køyrande prosessen lasta, ikkje den i upstream-handboka.

Skil så dei to laga folk blandar saman. OpenVPN har sine eigne TLS-kontrollar, inkludert ei innstilling for sertifikatprofil og eksplisitte chifferlister, og dei ligg over alt biblioteket handhevar. Å senke biblioteknivået endrar ikkje kva chiffere OpenVPN-konfigurasjonen din listar opp, og å snevre inn OpenVPN-lista hevar ikkje terskelen til biblioteket. Å vite kva lag som avviste deg, er det som hindrar at rettinga blir ei gissing.

Skil dei tre tinga som kan bli avviste

Den første kandidaten er identitetsmateriale: eit sertifikat der nøkkelen er for liten, eller der signaturalgoritmen ikkje lenger blir godtatt av policyen. Den andre er ein nøkkelutvekslingsparameter, som ei gruppe policyen ser på som for svak. Den tredje er ein chifferpakke policyen utelukkar. Alle tre kan gi ein handshake-feil, og berre feilteksten og forhandlingsfasen skil dei.

Ingen av dei tre er chifferen til datakanalen. OpenVPN forhandlar tunnelkrypteringa separat frå TLS-handshaken, så ei tilkopling som lukkast etter ei endring av tryggleiksnivået, seier ingenting om kva chiffer som vernar dataa dine. Viss spørsmålet du faktisk stiller, handlar om datakonfidensialitet, ser du på heilt feil knapp.

Å senke nivået utvidar aksepten for alle tre inndataa samstundes. Det er den delen folk overser: rettinga som slepp inn eit gammalt sertifikat, slepp også inn ei svak gruppe og ein pakke du kanskje ikkje hadde til hensikt å tillate. Éin feil utløyste endringa, og endringa er breiare enn feilen. Den asymmetrien er grunnen til at eit avgrensa unntak er betre enn ein standard for heile miljøet.

Endre inndataa, ikkje terskelen

Ta vare på den nøyaktige feilen før du rører konfigurasjonen, inkludert trinnet som rapporterte han, og objektet han namngav. Eit sertifikatproblem blir løyst ved å byte ut sertifikatet med noko dagens policy godtar, noko som vanlegvis tyder å utstede det på nytt hos autoriteten i staden for å installere den same fila på nytt.

Viss den avviste inndataa høyrer til ein peer du ikkje kontrollerer, er samtalen med eigaren hans om støtta erstatningsmateriale. Å senke din eigen terskel for å romme eit system ingen vedlikeheld, flyttar kostnaden frå dei til alle som koplar til etter dei.

Der serveren handhevar policyen, sjekk om ei innstilling på OpenVPN-nivå er den eigentlege årsaka før du klandrar biblioteket. Ein sertifikatprofil som krev ein strengare klasse enn det utrulla sertifikatet kan oppfylle, vil feile uansett tryggleiksnivå, og å fjerne profilen er ei snevrare endring enn å slå av kontrollane til biblioteket.

Viss du må senke det, avgrens og dokumenter det

Nokon gonger er eit godkjent kompatibilitetsunntak det rette svaret, særleg for ein eldre peer med ein datert utfasingsplan. Avgrens det til tenesta som treng det, i staden for heile verten: ei tenestespesifikk konfigurasjonsfil eller ein dedikert OpenSSL-konfigurasjon har mindre påverknadsradius enn ein eksport i den globale profilen.

Skriv ned fire ting saman med unntaket: den nøyaktige innstillinga, eigaren som godkjende det, klientane det påverkar, og vilkåret det blir fjerna under. Eit unntak utan utfasingsvilkår er ei varig svekking med ei mellombels grunngiving fest til.

Tilbakerulling bør vere eitt trinn du allereie har testa. Hald på den førre konfigurasjonen, bruk endringa, stadfest at tenesta startar, og vit nøyaktig kva fil du skal gjenopprette viss neste tilkopling oppfører seg annleis enn venta.

Stadfest identitet og vern etterpå

Ei vellukka tilkopling beviser berre at dei reviderte vilkåra sleppte ho inn. Stadfest at verifiseringa av vertsnamn og peer framleis gjer jobben sin, at sertifikatet som blir brukt, er det du meinte å rulle ut, og at den forhandla datakanalen svarar til policyen du trur du har.

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

OpenSSL-referansen for tryggleiksnivå seier eksplisitt at rammeverket legg grenser på nøklar, signaturar, grupper og pakkar samla, og at nivå null tillèt alt tilbakekallinga sjekkar. Det er omfanget av det du endra, og det er setninga å sitere når nokon spør om rettinga var smal.

Overleveringa som toler ein revisjon, seier kva policy som avviste kva inndata, kva som vart endra, og kva som framleis blir godtatt som følgje av det. „Det verkar med SECLEVEL=0“ er ein observasjon om éi tilkopling, ikkje ei tryggleiksvurdering av utrullinga.