SECLEVEL=0 behandler symptomet, ikke sertifikatet

En OpenVPN-tilkobling feiler, noen finner en rettelse på én linje som legger til SECLEVEL=0, og tunnelen kommer opp. Det som endret seg, var ikke sertifikatet og ikke chifferpakken; en akseptterskel for hele biblioteket flyttet seg, og alt prosessen gjør etterpå arver den nye grensen. Det er verdt å forstå før den samme linjen kopieres inn i hver profil i miljøet.

Finn ut hvilket bibliotek og hvilken policy som gjelder

SECLEVEL er et OpenSSL-begrep, så det første spørsmålet er om bygget ditt bruker OpenSSL i det hele tatt. OpenVPN kan kobles mot mer enn ett kryptografibibliotek, og en innstilling som gjelder for ett av dem, er meningsløs for de andre. Spør den binære filen hva den er bygget med, og spør deretter biblioteket hvilken versjon og konfigurasjon det lastet:

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

Les versjonsutskriften nøye, fordi distribusjoner patcher standardverdier. Noen leverer en systemkonfigurasjon som hever minimumsnivået over upstream-standarden, og derfor oppfører den samme profilen seg annerledes på to maskiner med identiske OpenVPN-pakker. Den effektive policyen er den kjørende prosessen lastet, ikke den i upstream-håndboken.

Skill så de to lagene folk blander sammen. OpenVPN har sine egne TLS-kontroller, inkludert en innstilling for sertifikatprofil og eksplisitte chifferlister, og de ligger over alt biblioteket håndhever. Å senke biblioteknivået endrer ikke hvilke chiffere OpenVPN-konfigurasjonen din lister opp, og å innsnevre OpenVPN-listen hever ikke bibliotekets terskel. Å vite hvilket lag som avviste deg, er det som hindrer at rettelsen blir en gjetning.

Skill de tre tingene som kan bli avvist

Den første kandidaten er identitetsmateriale: et sertifikat der nøkkelen er for liten, eller der signaturalgoritmen ikke lenger godtas av policyen. Den andre er en nøkkelutvekslingsparameter, som en gruppe policyen anser som for svak. Den tredje er en chifferpakke policyen utelukker. Alle tre kan gi en handshake-feil, og bare feilteksten og forhandlingsfasen skiller dem.

Ingen av de tre er datakanalens chiffer. OpenVPN forhandler tunnelkrypteringen separat fra TLS-handshaken, så en tilkobling som lykkes etter en endring av sikkerhetsnivået, sier ingenting om hvilken chiffer som beskytter dataene dine. Hvis spørsmålet du faktisk stiller, handler om datakonfidensialitet, ser du på helt feil knapp.

Å senke nivået utvider aksepten for alle tre innløpene samtidig. Det er den delen folk overser: rettelsen som slipper inn et gammelt sertifikat, slipper også inn en svak gruppe og en pakke du kanskje ikke hadde til hensikt å tillate. Én feil utløste endringen, og endringen er bredere enn feilen. Den asymmetrien er grunnen til at et avgrenset unntak er bedre enn en standard for hele miljøet.

Endre innløpet, ikke terskelen

Bevar den nøyaktige feilen før du rører konfigurasjonen, inkludert trinnet som rapporterte den, og objektet den navnga. Et sertifikatproblem løses ved å erstatte sertifikatet med noe dagens policy godtar, noe som vanligvis betyr å utstede det på nytt hos autoriteten i stedet for å installere den samme filen på nytt.

Hvis det avviste innløpet tilhører en peer du ikke kontrollerer, er samtalen med dens eier om støttet erstatningsmateriale. Å senke din egen terskel for å romme et system ingen vedlikeholder, flytter kostnaden fra dem til alle som kobler til etter dem.

Der serveren håndhever policyen, sjekk om en innstilling på OpenVPN-nivå er den egentlige årsaken før du klandrer biblioteket. En sertifikatprofil som krever en strengere klasse enn det utrullede sertifikatet kan oppfylle, vil feile uansett sikkerhetsnivå, og å fjerne profilen er en snevrere endring enn å slå av bibliotekets kontroller.

Hvis du må senke det, avgrens og dokumenter det

Noen ganger er et godkjent kompatibilitetsunntak det riktige svaret, særlig for en eldre peer med en datert utfasingsplan. Avgrens det til tjenesten som trenger det, i stedet for hele verten: en tjenestespesifikk konfigurasjonsfil eller en dedikert OpenSSL-konfigurasjon har mindre påvirkningsradius enn en eksport i den globale profilen.

Skriv ned fire ting sammen med unntaket: den nøyaktige innstillingen, eieren som godkjente det, klientene det påvirker, og betingelsen den fjernes under. Et unntak uten utfasingsbetingelse er en permanent svekkelse med en midlertidig begrunnelse festet til.

Tilbakerulling bør være ett trinn du allerede har testet. Behold den forrige konfigurasjonen, bruk endringen, bekreft at tjenesten starter, og vit nøyaktig hvilken fil du skal gjenopprette hvis neste tilkobling oppfører seg annerledes enn forventet.

Bekreft identitet og beskyttelse etterpå

En vellykket tilkobling beviser bare at de reviderte betingelsene slapp den inn. Bekreft at vertsnavn- og peer-verifiseringen fortsatt gjør jobben sin, at sertifikatet som brukes, er det du mente å rulle ut, og at den forhandlede datakanalen samsvarer med policyen 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

OpenSSL-referansen for sikkerhetsnivåer sier eksplisitt at rammeverket anvender grenser på nøkler, signaturer, grupper og pakker samlet, og at nivå null tillater alt tilbakeringingen sjekker. Det er omfanget av det du endret, og det er setningen å sitere når noen spør om rettelsen var snever.

Overleveringen som tåler en revisjon, sier hvilken policy som avviste hvilket innløp, hva som ble endret, og hva som fortsatt godtas som følge av det. „Det virker med SECLEVEL=0“ er en observasjon om én tilkobling, ikke en sikkerhetsvurdering av utrullingen.