SECLEVEL=0 verhelpt het symptoom, niet het certificaat

Een OpenVPN-verbinding mislukt, iemand vindt een oplossing van één regel die SECLEVEL=0 toevoegt, en de tunnel komt op. Wat veranderde was niet het certificaat en niet de ciphersuite; een acceptatiedrempel voor de hele bibliotheek verschoof, en alles wat het proces daarna doet erft de nieuwe grens. Dat is de moeite waard om te begrijpen voordat dezelfde regel in elk profiel in de omgeving wordt gekopieerd.

Stel vast welke bibliotheek en welk beleid van kracht zijn

SECLEVEL is een OpenSSL-concept, dus de eerste vraag is of je build überhaupt OpenSSL gebruikt. OpenVPN kan aan meer dan één cryptografiebibliotheek worden gekoppeld, en een instelling die voor één ervan geldt is zinloos voor de andere. Vraag het binaire bestand waarmee het is gebouwd, en vraag daarna de bibliotheek welke versie en configuratie zij heeft geladen:

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

Lees de versie-uitvoer zorgvuldig, want distributies patchen standaardwaarden. Sommige leveren een systeemconfiguratie die het minimumniveau boven de upstream-standaard verhoogt, en daarom gedraagt hetzelfde profiel zich anders op twee machines met identieke OpenVPN-pakketten. Het effectieve beleid is dat wat het draaiende proces heeft geladen, niet dat uit de upstream-handleiding.

Scheid daarna de twee lagen die mensen door elkaar halen. OpenVPN heeft zijn eigen TLS-besturing, waaronder een instelling voor het certificaatprofiel en expliciete cijferlijsten, en die staan boven alles wat de bibliotheek afdwingt. Het verlagen van het bibliotheekniveau verandert niet welke cijfers je OpenVPN-configuratie vermeldt, en het versmallen van de OpenVPN-lijst verhoogt de drempel van de bibliotheek niet. Weten welke laag je heeft geweigerd, is wat voorkomt dat de oplossing een gok blijft.

Scheid de drie dingen die geweigerd kunnen worden

De eerste kandidaat is identiteitsmateriaal: een certificaat waarvan de sleutel te klein is of waarvan het handtekeningalgoritme niet meer door het beleid wordt geaccepteerd. De tweede is een sleuteluitwisselingsparameter, zoals een groep die het beleid te zwak acht. De derde is een ciphersuite die het beleid uitsluit. Alle drie kunnen een handshake-fout veroorzaken, en alleen de fouttekst en de onderhandelingsfase onderscheiden ze.

Geen van die drie is het cijfer van het datakanaal. OpenVPN onderhandelt zijn tunnelversleuteling apart van de TLS-handshake, dus een verbinding die na een wijziging van het beveiligingsniveau slaagt, zegt niets over welk cijfer je gegevens beschermt. Als de vraag die je eigenlijk stelt over de vertrouwelijkheid van gegevens gaat, kijk je naar de volledig verkeerde knop.

Het verlagen van het niveau verruimt de acceptatie voor alle drie de invoeren tegelijk. Dat is het deel dat mensen missen: de oplossing die een oud certificaat toelaat, laat ook een zwakke groep en een suite toe die je misschien niet van plan was toe te staan. Eén fout leidde tot de wijziging, en de wijziging is breder dan de fout. Die asymmetrie is de reden waarom een beperkte uitzondering beter is dan een standaard voor de hele omgeving.

Verander de invoer, niet de drempel

Bewaar de exacte fout voordat je de configuratie aanraakt, inclusief de fase die hem meldde en het object dat hij noemde. Een certificaatprobleem wordt opgelost door het certificaat te vervangen door iets wat het huidige beleid accepteert, wat meestal betekent dat je het bij de autoriteit opnieuw uitgeeft in plaats van hetzelfde bestand opnieuw te installeren.

Als de geweigerde invoer bij een peer hoort die je niet beheert, is het gesprek met de eigenaar daarvan over ondersteund vervangend materiaal. Je eigen drempel verlagen om een systeem te huisvesten dat niemand onderhoudt, verplaatst de kosten van hen naar iedereen die daarna verbinding maakt.

Waar de server het beleid handhaaft, controleer of een instelling op OpenVPN-niveau de werkelijke oorzaak is voordat je de bibliotheek de schuld geeft. Een certificaatprofiel dat een strengere klasse eist dan het uitgerolde certificaat kan vervullen, zal mislukken ongeacht het beveiligingsniveau, en dat profiel verwijderen is een smallere wijziging dan de controles van de bibliotheek uitschakelen.

Als je het moet verlagen, begrens en documenteer het

Soms is een goedgekeurde compatibiliteitsuitzondering het juiste antwoord, vooral voor een oude peer met een gedateerd uitfaseringsplan. Beperk hem tot de dienst die hem nodig heeft in plaats van de hele host: een dienstspecifiek configuratiebestand of een aparte OpenSSL-configuratie heeft een kleinere impactstraal dan een export in het globale profiel.

Schrijf vier dingen bij de uitzondering: de exacte instelling, de eigenaar die hem goedkeurde, de clients die erdoor worden geraakt, en de voorwaarde waaronder hij wordt verwijderd. Een uitzondering zonder uitfaseringsvoorwaarde is een blijvende verzwakking met een tijdelijke rechtvaardiging eraan vast.

Terugdraaien moet één stap zijn die je al hebt getest. Bewaar de vorige configuratie, pas de wijziging toe, bevestig dat de dienst start, en weet precies welk bestand je moet herstellen als de volgende verbinding zich anders gedraagt dan verwacht.

Verifieer daarna identiteit en bescherming

Een geslaagde verbinding bewijst alleen dat de herziene voorwaarden hem hebben toegelaten. Bevestig dat de verificatie van hostnaam en peer nog steeds zijn werk doet, dat het gebruikte certificaat het certificaat is dat je wilde uitrollen, en dat het onderhandelde datakanaal overeenkomt met het beleid waarvan je denkt dat je het hebt.

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

De OpenSSL-referentie voor beveiligingsniveaus zegt uitdrukkelijk dat het framework grenzen stelt aan sleutels, handtekeningen, groepen en suites samen, en dat niveau nul alles toestaat wat de callback controleert. Dat is de reikwijdte van wat je hebt veranderd, en dat is de zin die je citeert als iemand vraagt of de oplossing smal was.

De overdracht die een audit doorstaat, zegt welk beleid welke invoer weigerde, wat er is gewijzigd en wat daardoor nog wordt geaccepteerd. „Het werkt met SECLEVEL=0“ is een observatie over één verbinding, geen beveiligingsbeoordeling van de uitrol.