SECLEVEL=0 hoitaa oireen, ei sertifikaattia
OpenSSL:n suojaustason laskeminen laajentaa sitä, mitä kirjasto hyväksyy. Selvitä, mikä syöte hylättiin, ennen kuin muutat rajaa koko isännälle.
OpenVPN-yhteys epäonnistuu, joku löytää yhden rivin korjauksen, joka lisää SECLEVEL=0:n, ja tunneli nousee. Muutos ei ollut sertifikaatti eikä salausohjelmistopaketti; kirjastotasoinen hyväksymiskynnys siirtyi, ja kaikki, mitä prosessi sen jälkeen tekee, perii uuden rajan. Se on syytä ymmärtää, ennen kuin sama rivi kopioidaan jokaiseen profiiliin ympäristössä.
Selvitä, mikä kirjasto ja mikä käytäntö ovat voimassa
SECLEVEL on OpenSSL:n käsite, joten ensimmäinen kysymys on, käyttääkö koontiversiosi OpenSSL:ää lainkaan. OpenVPN voidaan linkittää useampaan kuin yhteen kryptografia kirjastoon, ja yhteen niistä soveltuva asetus on merkityksetön muille. Kysy binääriltä, millä se on koottu, ja kysy sitten kirjastolta, minkä version ja kokoonpanon se latasi:
openvpn --version | head -3
openssl version -aLue version tuloste huolellisesti, koska jakelut paikkaavat oletuksia. Jotkin toimittavat järjestelmäkokoonpanon, joka nostaa vähimmäistason upstreamin oletuksen yläpuolelle, ja siksi sama profiili käyttäytyy eri tavalla kahdessa koneessa, joissa on samat OpenVPN-paketit. Voimassa oleva käytäntö on se, jonka käynnissä oleva prosessi latasi, ei upstreamin käsikirjan.
Erottele sitten kaksi kerrosta, jotka ihmiset sekoittavat. OpenVPN:llä on omat TLS-ohjauksensa, mukaan lukien sertifikaattiprofiilin asetus ja eksplisiittiset salauslistat, ja ne ovat kaiken sen yläpuolella, mitä kirjasto pakottaa. Kirjaston tason laskeminen ei muuta sitä, mitkä salaukset OpenVPN-kokoonpanosi luettelee, eikä OpenVPN-listan kaventaminen nosta kirjaston kynnystä. Tieto siitä, mikä kerros hylkäsi sinut, estää korjausta jäämästä arvaukseksi.
Erottele kolme asiaa, jotka voidaan hylätä
Ensimmäinen ehdokas on identiteettimateriaali: sertifikaatti, jonka avain on liian pieni tai jonka allekirjoitusalgoritmia käytäntö ei enää hyväksy. Toinen on avaintenvaihtoparametri, kuten ryhmä, jota käytäntö pitää liian heikkona. Kolmas on salauspaketti, jonka käytäntö sulkee pois. Kaikki kolme voivat aiheuttaa kättelyvirheen, ja vain virheteksti ja neuvotteluvaihe erottavat ne.
Mikään noista kolmesta ei ole datakanavan salaus. OpenVPN neuvottelee tunnelinsa salauksen erikseen TLS-kättelystä, joten yhteys, joka onnistuu suojaustason muutoksen jälkeen, ei kerro mitään siitä, mikä salaus suojaa tietojasi. Jos kysymys, jonka todella esität, koskee tietojen luottamuksellisuutta, katsot täysin väärää nuppia.
Tason laskeminen laajentaa hyväksyntää kaikille kolmelle syötteelle kerralla. Tämä on se osa, jonka ihmiset jättävät huomaamatta: korjaus, joka päästää vanhan sertifikaatin läpi, päästää myös heikon ryhmän ja paketin, jota et ehkä aikonut sallia. Yksi virhe sai muutoksen aikaan, ja muutos on virhettä laajempi. Tämä epäsymmetria on syy siihen, miksi rajattu poikkeus on parempi kuin koko ympäristön oletus.
Muuta syötettä, älä kynnystä
Säilytä tarkka virhe ennen kokoonpanon koskemista, mukaan lukien vaihe, joka sen ilmoitti, ja objekti, jonka se nimesi. Sertifikaattiongelma ratkaistaan korvaamalla sertifikaatti jollakin, jonka nykyinen käytäntö hyväksyy, mikä yleensä tarkoittaa sen myöntämistä uudelleen viranomaiselta saman tiedoston uudelleenasentamisen sijaan.
Jos hylätty syöte kuuluu vertaiselle, jota et hallitse, keskustelu käydään sen omistajan kanssa tuetusta korvaavasta materiaalista. Oman kynnyksen laskeminen sellaisen järjestelmän vuoksi, jota kukaan ei ylläpidä, siirtää kustannuksen heiltä kaikille, jotka yhdistävät heidän jälkeensä.
Missä palvelin valvoo käytäntöä, tarkista ennen kirjaston syyttämistä, onko OpenVPN-tason asetus todellinen syy. Sertifikaattiprofiili, joka vaatii tiukempaa luokkaa kuin käyttöön otettu sertifikaatti pystyy täyttämään, epäonnistuu riippumatta suojaustasosta, ja profiilin poistaminen on kapeampi muutos kuin kirjaston tarkistusten poistaminen käytöstä.
Jos sinun on laskettava sitä, rajata se ja kirjaa se
Joskus hyväksytty yhteensopivuuspoikkeus on oikea vastaus, erityisesti vanhalle vertaiselle, jolla on päivätty poistumissuunnitelma. Rajaa se palveluun, joka sitä tarvitsee, koko isännän sijaan: palvelukohtainen kokoonpanotiedosto tai erillinen OpenSSL-kokoonpano vaikuttaa pienemmällä säteellä kuin vienti globaalissa profiilissa.
Kirjoita poikkeuksen yhteyteen neljä asiaa: tarkka asetus, sen hyväksynyt omistaja, asiakkaat, joihin se vaikuttaa, ja ehto, jolla se poistetaan. Poikkeus ilman poistumisehtoa on pysyvä heikennys, johon on liitetty väliaikainen perustelu.
Palautuksen pitäisi olla yksi vaihe, jonka olet jo testannut. Säilytä edellinen kokoonpano, ota muutos käyttöön, varmista, että palvelu käynnistyy, ja tiedä tarkalleen, mikä tiedosto palauttaa, jos seuraava yhteys käyttäytyy odottamattomasti.
Vahvista identiteetti ja suojaus jälkeenpäin
Onnistunut yhteys todistaa vain, että tarkistetut ehdot päästivät sen läpi. Varmista, että isäntänimen ja vertaisen tarkistus tekee edelleen tehtävänsä, että käytössä oleva sertifikaatti on se, jonka aioit ottaa käyttöön, ja että neuvoteltu datakanava vastaa käytäntöä, jonka luulet olevan voimassa.
openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20OpenSSL:n suojaustasojen viite sanoo selvästi, että kehys soveltaa rajoja avaimiin, allekirjoituksiin, ryhmiin ja paketteihin yhdessä ja että nollataso sallii kaiken, mitä takaisinkutsu tarkistaa. Se on sen laajuus, mitä muutit, ja se on lause, joka siteerataan, kun joku kysyy, oliko korjaus kapea.
Auditoinnin kestävä luovutus kertoo, mikä käytäntö hylkäsi minkä syötteen, mitä muutettiin ja mitä sen seurauksena hyväksytään edelleen. „Se toimii SECLEVEL=0:lla“ on havainto yhdestä yhteydestä, ei käyttöönoton turvallisuusarvio.