SECLEVEL=0 botar symptomet, inte certifikatet

En OpenVPN-anslutning misslyckas, någon hittar en radfix som lägger till SECLEVEL=0, och tunneln kommer upp. Det som ändrades var inte certifikatet och inte chifferpaketet; en accepttröskel för hela biblioteket flyttades, och allt processen gör efteråt ärver den nya gränsen. Det är värt att förstå innan samma rad kopieras in i varje profil i miljön.

Ta reda på vilket bibliotek och vilken policy som gäller

SECLEVEL är ett OpenSSL-begrepp, så den första frågan är om din build använder OpenSSL över huvud taget. OpenVPN kan länkas mot mer än ett kryptografibibliotek, och en inställning som gäller för ett av dem är meningslös för de andra. Fråga den binära filen vad den byggdes med och fråga sedan biblioteket vilken version och konfiguration det laddade:

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

Läs versionsutskriften noga, eftersom distributioner patchar standardvärden. Vissa levererar en systemkonfiguration som höjer miniminivån över upstream-standardvärdet, och därför beter sig samma profil olika på två maskiner med identiska OpenVPN-paket. Den effektiva policyn är den som den körande processen laddade, inte den i upstream-handboken.

Separera sedan de två lager som folk blandar ihop. OpenVPN har egna TLS-kontroller, inklusive en inställning för certifikatprofil och explicita chifferlistor, och de ligger över allt biblioteket genomdriver. Att sänka biblioteksnivån ändrar inte vilka chiffer din OpenVPN-konfiguration listar, och att snäva in OpenVPN-listan höjer inte bibliotekets tröskel. Att veta vilket lager som avvisade dig är det som hindrar fixen från att förbli en gissning.

Separera de tre saker som kan avvisas

Den första kandidaten är identitetsmaterial: ett certifikat vars nyckel är för liten eller vars signaturalgoritm policyn inte längre accepterar. Den andra är en nyckelutbytesparameter, som en grupp policyn anser vara för svag. Den tredje är ett chifferpaket som policyn utesluter. Alla tre kan ge ett handskakningsfel, och bara feltexten och förhandlingsfasen skiljer dem åt.

Ingen av de tre är datakanalens chiffer. OpenVPN förhandlar tunnelkrypteringen separat från TLS-handskakningen, så en anslutning som lyckas efter en ändring av säkerhetsnivån säger ingenting om vilket chiffer som skyddar dina data. Om frågan du faktiskt ställer handlar om datasekretess tittar du på helt fel ratt.

Att sänka nivån vidgar acceptansen för alla tre indata samtidigt. Det är den delen folk missar: fixen som släpper in ett gammalt certifikat släpper också in en svag grupp och ett paket du kanske inte hade för avsikt att tillåta. Ett enda fel utlöste ändringen, och ändringen är bredare än felet. Den asymmetrin är anledningen till att ett avgränsat undantag är bättre än en standard för hela miljön.

Ändra indata, inte tröskeln

Bevara det exakta felet innan du rör konfigurationen, inklusive steget som rapporterade det och objektet det namngav. Ett certifikatproblem löses genom att ersätta certifikatet med något som den aktuella policyn accepterar, vilket vanligtvis innebär att utfärda det på nytt hos utfärdaren i stället för att installera om samma fil.

Om den avvisade indatan tillhör en peer du inte kontrollerar är samtalet med dess ägare om underhållet ersättningsmaterial. Att sänka din egen tröskel för att husera ett system som ingen underhåller flyttar kostnaden från dem till alla som ansluter efter dem.

Där servern genomdriver policyn, kontrollera om en inställning på OpenVPN-nivå är den egentliga orsaken innan du skyller på biblioteket. En certifikatprofil som kräver en strängare klass än det utrullade certifikatet kan uppfylla kommer att misslyckas oavsett säkerhetsnivå, och att ta bort profilen är en snävare ändring än att stänga av bibliotekets kontroller.

Om du måste sänka det, avgränsa och dokumentera det

Ibland är ett godkänt kompatibilitetsundantag rätt svar, särskilt för en äldre peer med en daterad avvecklingsplan. Avgränsa det till tjänsten som behöver det i stället för hela värden: en tjänstespecifik konfigurationsfil eller en dedikerad OpenSSL-konfiguration har mindre påverkansradie än en export i den globala profilen.

Skriv ner fyra saker tillsammans med undantaget: den exakta inställningen, ägaren som godkände det, klienterna det påverkar och villkoret under vilket det tas bort. Ett undantag utan avvecklingsvillkor är en permanent försvagning med en tillfällig motivering bifogad.

Återställningen bör vara ett enda steg som du redan har testat. Behåll den tidigare konfigurationen, tillämpa ändringen, bekräfta att tjänsten startar och vet exakt vilken fil du ska återställa om nästa anslutning beter sig annorlunda än väntat.

Verifiera identitet och skydd efteråt

En lyckad anslutning bevisar bara att de reviderade villkoren släppte in den. Bekräfta att verifieringen av värdnamn och peer fortfarande gör sitt jobb, att certifikatet som används är det du avsåg att rulla ut och att den förhandlade datakanalen motsvarar policyn du tror att 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:s referens för säkerhetsnivåer säger uttryckligen att ramverket tillämpar gränser på nycklar, signaturer, grupper och paket tillsammans, och att nivå noll tillåter allt som återanropet kontrollerar. Det är omfattningen av det du ändrade, och det är meningen att citera när någon frågar om fixen var snäv.

Överlämningen som klarar en granskning säger vilken policy som avvisade vilken indata, vad som ändrades och vad som fortsatt accepteras som ett resultat. „Det fungerar med SECLEVEL=0“ är en observation om en anslutning, inte en säkerhetsbedömning av utrullningen.