SECLEVEL=0 léčí symptom, ne certifikát

Připojení OpenVPN selže, někdo najde jednořádkovou opravu, která přidá SECLEVEL=0, a tunel naskočí. Nezměnil se certifikát ani sada šifer; posunula se prahová hodnota přijetí na úrovni knihovny a vše, co proces potom dělá, dědí novou hranici. Stojí za to to pochopit dřív, než se stejný řádek zkopíruje do každého profilu v prostředí.

Určete, která knihovna a která zásada platí

SECLEVEL je koncept OpenSSL, takže první otázka je, zda váš build vůbec OpenSSL používá. OpenVPN lze propojit s více než jednou kryptografickou knihovnou a nastavení, které platí pro jednu z nich, je pro ostatní bezvýznamné. Zeptejte se binárky, s čím byla sestavena, a potom se zeptejte knihovny, kterou verzi a konfiguraci načetla:

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

Čtěte výstup verze pozorně, protože distribuce záplatují výchozí hodnoty. Některé dodávají systémovou konfiguraci, která zvyšuje minimální úroveň nad výchozí hodnotu upstreamu, a proto se stejný profil chová odlišně na dvou strojích se shodnými balíčky OpenVPN. Účinná zásada je ta, kterou načetl běžící proces, ne ta z příručky upstreamu.

Potom oddělte dvě vrstvy, které lidé slučují. OpenVPN má vlastní TLS ovládání, včetně nastavení profilu certifikátu a explicitních seznamů šifer, a ta stojí nad vším, co knihovna vynucuje. Snížení úrovně knihovny nemění, které šifry váš konfigurace OpenVPN uvádí, a zúžení seznamu OpenVPN nezvyšuje prahovou hodnotu knihovny. Vědět, která vrstva vás odmítla, je to, co brání tomu, aby oprava zůstala hádankou.

Oddělte tři věci, které mohou být odmítnuty

Prvním kandidátem je identitní materiál: certifikát, jehož klíč je příliš malý nebo jehož podpisový algoritmus zásada už nepřijímá. Druhým je parametr výměny klíčů, například skupina, kterou zásada považuje za příliš slabou. Třetím je sada šifer, kterou zásada vylučuje. Všechny tři mohou způsobit selhání handshake a rozliší je jen text chyby a fáze vyjednávání.

Žádný z těch tří není šifra datového kanálu. OpenVPN vyjednává šifrování tunelu odděleně od TLS handshake, takže spojení, které po změně bezpečnostní úrovně uspěje, nic neříká o tom, která šifra chrání váš obsah. Pokud se otázka, kterou skutečně kladete, týká důvěrnosti dat, díváte se na zcela špatný knoflík.

Snížení úrovně rozšiřuje přijetí všech tří vstupů najednou. To je část, kterou lidé přehlížejí: oprava, která pustí starý certifikát, pustí také slabou skupinu a sadu, kterou jste možná povolit nechtěli. Změnu vyvolala jediná chyba a změna je širší než chyba. Tato asymetrie je důvod, proč je omezená výjimka lepší než výchozí hodnota pro celé prostředí.

Změňte vstup, ne prahovou hodnotu

Zachovejte přesnou chybu, než se dotknete konfigurace, včetně fáze, která ji nahlásila, a objektu, který pojmenovala. Problém s certifikátem se řeší nahrazením certifikátu něčím, co současná zásada přijímá, což obvykle znamená znovuvydání u autority, nikoli přeinstalování stejného souboru.

Pokud odmítnutý vstup patří peerovi, který neovládáte, jde o rozhovor s jeho vlastníkem o podporovaném náhradním materiálu. Snížení vlastního prahu kvůli systému, který nikdo neudržuje, přesouvá náklady z něj na všechny, kdo se připojí po něm.

Kde server vynucuje zásadu, zkontrolujte, zda není skutečnou příčinou nastavení na úrovni OpenVPN, dřív než obviníte knihovnu. Profil certifikátu, který žádá přísnější třídu, než nasazený certifikát může splnit, selže bez ohledu na nastavenou bezpečnostní úroveň, a odstranění tohoto profilu je užší změnou než vypnutí kontrol knihovny.

Pokud ji musíte snížit, ohraničte ji a zaznamenejte

Někdy je schválená výjimka kvůli kompatibilitě správnou odpovědí, zejména pro starý peer s datovaným plánem vyřazení. Ohraničte ji na službu, která ji potřebuje, ne na celý hostitel: konfigurační soubor pro konkrétní službu nebo vyhrazená konfigurace OpenSSL má menší dopad než export v globálním profilu.

K výjimce napište čtyři věci: přesné nastavení, vlastníka, který ji schválil, klienty, které ovlivňuje, a podmínku, za které bude odstraněna. Výjimka bez podmínky vyřazení je trvalé oslabení s připojeným dočasným odůvodněním.

Vrácení zpět by mělo být jediným krokem, který jste už otestovali. Ponechte předchozí konfiguraci, aplikujte změnu, potvrďte, že se služba spustí, a vězte přesně, který soubor obnovit, pokud se příští připojení zachová jinak, než očekáváte.

Poté ověřte identitu a ochranu

Úspěšné připojení dokazuje jen to, že je revidované podmínky pustily. Potvrďte, že ověřování názvu hostitele a peera stále dělá svou práci, že používaný certifikát je ten, který jste chtěli nasadit, a že vyjednaný datový kanál odpovídá zásadě, o níž si myslíte, že ji máte.

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

Referenční dokumentace OpenSSL k bezpečnostním úrovním výslovně uvádí, že rámec uplatňuje limity na klíče, podpisy, skupiny a sady společně a že nulová úroveň povoluje vše, co zpětné volání kontroluje. To je rozsah toho, co jste změnili, a to je věta, kterou citovat, když se někdo ptá, zda byla oprava úzká.

Předání, které přežije audit, říká, která zásada odmítla který vstup, co bylo změněno a co zůstává přijato. „Funguje to se SECLEVEL=0“ je pozorování o jednom připojení, ne bezpečnostní hodnocení nasazení.