SECLEVEL=0 kurerer symptomet, ikke certifikatet

En OpenVPN-forbindelse fejler, nogen finder en rettelse på én linje, der tilføjer SECLEVEL=0, og tunnelen kommer op. Det, der ændrede sig, var ikke certifikatet og ikke cifferpakken; en accepttærskel for hele biblioteket flyttede sig, og alt, hvad processen gør bagefter, arver den nye grænse. Det er værd at forstå, før den samme linje kopieres ind i hver profil i miljøet.

Find ud af, hvilket bibliotek og hvilken politik der gælder

SECLEVEL er et OpenSSL-begreb, så det første spørgsmål er, om din build overhovedet bruger OpenSSL. OpenVPN kan linkes mod mere end ét kryptografibibliotek, og en indstilling, der gælder for ét af dem, er meningsløs for de andre. Spørg den binære fil, hvad den er bygget med, og spørg derefter biblioteket, hvilken version og konfiguration det har indlæst:

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

Læs versionsoutputtet omhyggeligt, fordi distributioner patcher standardværdier. Nogle leverer en systemkonfiguration, der hæver minimumsniveauet over upstream-standarden, og derfor opfører den samme profil sig forskelligt på to maskiner med identiske OpenVPN-pakker. Den effektive politik er den, den kørende proces har indlæst, ikke den i upstream-manualen.

Adskil derefter de to lag, som folk blander sammen. OpenVPN har sine egne TLS-kontroller, herunder en indstilling for certifikatprofil og eksplicitte cifferlister, og de ligger over det, biblioteket håndhæver. At sænke biblioteksniveauet ændrer ikke, hvilke cifre din OpenVPN-konfiguration oplister, og at indsnævre OpenVPN-listen hæver ikke bibliotekets tærskel. At vide, hvilket lag der afviste dig, er det, der forhindrer, at rettelsen bliver et gæt.

Adskil de tre ting, der kan blive afvist

Den første kandidat er identitetsmateriale: et certifikat, hvis nøgle er for lille, eller hvis signaturalgoritme politikken ikke længere accepterer. Den anden er en nøgleudvekslingsparameter, såsom en gruppe, som politikken anser for svag. Den tredje er en cifferpakke, som politikken udelukker. Alle tre kan give en handshake-fejl, og kun fejlteksten og forhandlingsfasen adskiller dem.

Ingen af de tre er data-kanalens ciffer. OpenVPN forhandler sin tunnelkryptering separat fra TLS-handshaket, så en forbindelse, der lykkes efter en ændring af sikkerhedsniveauet, siger intet om, hvilken ciffer der beskytter dine data. Hvis spørgsmålet, du faktisk stiller, handler om datafortrolighed, kigger du på den helt forkerte knap.

At sænke niveauet udvider accepten for alle tre input på én gang. Det er den del, folk overser: rettelsen, der lukker et gammelt certifikat ind, lukker også en svag gruppe og en pakke ind, som du måske ikke havde til hensigt at tillade. En enkelt fejl udløste ændringen, og ændringen er bredere end fejlen. Den asymmetri er grunden til, at en afgrænset undtagelse er bedre end en standard for hele miljøet.

Ændr inputtet, ikke tærsklen

Bevar den præcise fejl, før du rører konfigurationen, inklusive det trin, der rapporterede den, og det objekt, den navngav. Et certifikatproblem løses ved at erstatte certifikatet med noget, den aktuelle politik accepterer, hvilket normalt betyder at genudstede det hos autoriteten i stedet for at geninstallere den samme fil.

Hvis det afviste input tilhører en peer, du ikke kontrollerer, er samtalen med den peers ejer om understøttet erstatningsmateriale. At sænke din egen tærskel for at rumme et system, ingen vedligeholder, flytter omkostningen fra dem til alle, der forbinder efter dem.

Hvor serveren håndhæver politikken, skal du kontrollere, om en indstilling på OpenVPN-niveau er den egentlige årsag, før du bebrejder biblioteket. En certifikatprofil, der kræver en strengere klasse, end det udrullede certifikat kan opfylde, vil fejle uanset sikkerhedsniveauet, og at fjerne profilen er en snævrere ændring end at slå bibliotekets kontroller fra.

Hvis du må sænke det, afgræns og dokumentér det

Nogle gange er en godkendt kompatibilitetsundtagelse det rigtige svar, især for en ældre peer med en dateret udfasningsplan. Afgræns den til den tjeneste, der har brug for den, i stedet for hele værten: en tjenestespecifik konfigurationsfil eller en dedikeret OpenSSL-konfiguration har en mindre påvirkningsradius end en eksport i den globale profil.

Skriv fire ting ned sammen med undtagelsen: den præcise indstilling, den ejer der godkendte den, de klienter den påvirker, og den betingelse, hvorunder den fjernes. En undtagelse uden udfasningsbetingelse er en permanent svækkelse med en midlertidig begrundelse hæftet på.

Tilbagerulning bør være et enkelt trin, du allerede har testet. Behold den forrige konfiguration, anvend ændringen, bekræft, at tjenesten starter, og vid præcis, hvilken fil der skal gendannes, hvis den næste forbindelse opfører sig anderledes end forventet.

Bekræft identitet og beskyttelse bagefter

En vellykket forbindelse beviser kun, at de reviderede betingelser lukkede den ind. Bekræft, at værtsnavn- og peer-verifikation stadig gør deres arbejde, at det anvendte certifikat er det, du havde til hensigt at udrulle, og at den forhandlede datakanal svarer til den politik, du tror, du har.

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

OpenSSLs reference til sikkerhedsniveauer siger udtrykkeligt, at rammen anvender grænser på nøgler, signaturer, grupper og pakker samlet, og at niveau nul tillader alt, hvad callbacket kontrollerer. Det er omfanget af det, du ændrede, og det er den sætning, du bør citere, når nogen spørger, om rettelsen var snæver.

Den overdragelse, der overlever en revision, siger, hvilken politik der afviste hvilket input, hvad der blev ændret, og hvad der som følge heraf stadig accepteres. „Det virker med SECLEVEL=0“ er en observation om én forbindelse, ikke en sikkerhedsvurdering af udrulningen.