SECLEVEL=0 genees die simptoom, nie die sertifikaat nie

’n OpenVPN-verbinding misluk, iemand vind ’n eenreëlregstelling wat SECLEVEL=0 byvoeg, en die tonnel kom op. Wat verander het, was nie die sertifikaat en nie die cipher suite nie; ’n bibliotekwye aanvaardingsdrempel het geskuif, en alles wat die proses daarna doen, erf die nuwe grens. Dit is die moeite werd om te verstaan voordat dieselfde reël in elke profiel in die omgewing gekopieer word.

Stel vas watter biblioteek en watter beleid geld

SECLEVEL is ’n OpenSSL-konsep, so die eerste vraag is of jou bou eerder OpenSSL gebruik. OpenVPN kan teen meer as een kriptografiebiblioteek geskakel word, en ’n instelling wat vir een daarvan geld, is betekenisloos vir die ander. Vra die binêre lêer waarmee dit gebou is, en vra dan die biblioteek watter weergawe en konfigurasie dit gelaai het:

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

Lees die weergawe-uitset noukeurig, want verspreidings pas verstekke aan. Sommige lewer ’n stelselkonfigurasie wat die minimumvlak bo die opstroom-verstek verhoog, en daarom gedra dieselfde profiel hom anders op twee masjiene met identiese OpenVPN-pakkette. Die effektiewe beleid is die een wat die lopende proses gelaai het, nie die een in die opstroom-handleiding nie.

Skei dan die twee lae wat mense verwar. OpenVPN het sy eie TLS-beheermaatreëls, insluitend ’n instelling vir die sertifikaatprofiel en eksplisiete cipher-lyste, en dié sit bo alles wat die biblioteek afdwing. Om die biblioteekvlak te verlaag, verander nie watter ciphers jou OpenVPN-konfigurasie lys nie, en om die OpenVPN-lys te vernou, verhoog nie die biblioteek se drempel nie. Om te weet watter laag jou geweier het, is wat keer dat die regstelling ’n raaiskoot bly.

Skei die drie dinge wat verwerp kan word

Die eerste kandidaat is identiteitsmateriaal: ’n sertifikaat waarvan die sleutel te klein is of waarvan die handtekeningalgoritme nie meer deur die beleid aanvaar word nie. Die tweede is ’n sleuteluitruil-parameter, soos ’n groep wat die beleid as te swak beskou. Die derde is ’n cipher suite wat die beleid uitsluit. Al drie kan ’n handshake-fout veroorsaak, en net die foutteks en die onderhandelingsfase onderskei hulle.

Nie een van dié drie is die datakanaal-cipher nie. OpenVPN onderhandel sy tonnelversleuteling apart van die TLS-handshake, dus ’n verbinding wat ná ’n verandering in sekuriteitsvlak slaag, sê niks oor watter cipher jou nutslading beskerm nie. As die vraag wat jy eintlik vra oor die vertroulikheid van data gaan, kyk jy heeltemal na die verkeerde knop.

Om die vlak te verlaag, verbreed die aanvaarding vir al drie invoere tegelyk. Dit is die deel wat mense mis: die regstelling wat ’n ou sertifikaat toelaat, laat ook ’n swak groep en ’n suite toe wat jy dalk nie bedoel het om toe te laat nie. ’n Enkele fout het die verandering veroorsaak, en die verandering is breër as die fout. Dié asimmetrie is die rede waarom ’n beperkte uitsondering beter is as ’n verstek vir die hele omgewing.

Verander die invoer, nie die drempel nie

Bewaar die presiese fout voordat jy aan die konfigurasie raak, insluitend die fase wat dit gerapporteer het en die objek wat dit genoem het. ’n Sertifikaatprobleem word opgelos deur die sertifikaat te vervang met iets wat die huidige beleid aanvaar, wat gewoonlik beteken om dit by die owerheid te heruitreik eerder as om dieselfde lêer weer te installeer.

As die verwerpte invoer aan ’n peer behoort wat jy nie beheer nie, is die gesprek met daardie peer se eienaar oor ondersteunde vervangingsmateriaal. Om jou eie drempel te verlaag om ’n stelsel te akkommodeer wat niemand onderhou nie, verskuif die koste van hulle na almal wat daarna verbind.

Waar die bediener die beleid afdwing, kyk of ’n instelling op OpenVPN-vlak die werklike oorsaak is voordat jy die biblioteek blameer. ’n Sertifikaatprofiel wat ’n strenger klas vra as wat die ontplooide sertifikaat kan bevredig, sal misluk maak nie saak waarop die sekuriteitsvlak gestel is nie, en om daardie profiel te verwyder is ’n smaller verandering as om biblioteekkontroles af te skakel.

As jy dit moet verlaag, beperk dit en teken dit aan

Soms is ’n goedgekeurde versoenbaarheidsuitsondering die regte antwoord, veral vir ’n legacy-peer met ’n gedateerde aftreeplan. Beperk dit tot die diens wat dit nodig het eerder as die hele gasheer: ’n diensspesifieke konfigurasielêer of ’n toegewyde OpenSSL-konfigurasie het ’n kleiner impakarea as ’n uitvoer in die globale profiel.

Skryf vier dinge by die uitsondering neer: die presiese instelling, die eienaar wat dit goedgekeur het, die kliënte wat dit raak, en die voorwaarde waaronder dit verwyder word. ’n Uitsondering sonder ’n aftreevoorwaarde is ’n permanente verswakking met ’n tydelike regverdiging daarby.

Terugrol behoort ’n enkele stap te wees wat jy reeds getoets het. Hou die vorige konfigurasie, pas die verandering toe, bevestig dat die diens begin, en weet presies watter lêer om te herstel as die volgende verbinding anders optree as wat verwag is.

Verifieer identiteit en beskerming daarna

’n Suksesvolle verbinding bewys net dat die hersiene voorwaardes dit toegelaat het. Bevestig dat gasheernaam- en peer-verifikasie nog hul werk doen, dat die sertifikaat in gebruik die een is wat jy bedoel het om te ontplooi, en dat die onderhandelde datakanaal ooreenstem met die beleid wat jy dink jy het.

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

Die OpenSSL-verwysing vir sekuriteitsvlakke sê uitdruklik dat die raamwerk grense oor sleutels, handtekeninge, groepe en suites saam toepas, en dat vlak nul alles toelaat wat die callback nagaan. Dit is die omvang van wat jy verander het, en dit is die sin om aan te haal wanneer iemand vra of die regstelling eng was.

Die oorhandiging wat ’n oudit oorleef, sê watter beleid watter invoer verwerp het, wat verander is en wat gevolglik aanvaar bly. “Dit werk met SECLEVEL=0” is ’n waarneming oor een verbinding, nie ’n sekuriteitsbeoordeling van die ontplooiing nie.