OpenVPN-i võtmeviip pärast OpenSSL 3: kontrollige pakkujat

Keegi ei puutunud profiili, kuid sama klient nõuab nüüd igal käivitamisel privaatvõtme paroolifraasi. Kui see muutus ilmneb mõni päev pärast distributsiooni uuendust, on tõenäoline põhjus uuendus ise: OpenSSL 3 korraldas algoritmitoe ümber ja võti, mida vana teek luges vaevata, võib muutuda loetamatuks, ilma et ükski bait muutuks. Tehke kontrollid järjekorras, sest kaks neist näevad ainult viipa vaadates identsed välja.

Esimene küsimus on, kas võti on krüpteeritud, ja teine, kas see build suudab selle dekrüpteerida. Konfiguratsioonimuudatustel on mõtet alles siis, kui mõlemad vastused on teada.

Kontrollige, kas võti on krüpteeritud

Lugege faili esimest rida ja laske seejärel teegil see parsida, sest failinimi ei tõesta midagi. PEM-plokk märgisega ENCRYPTED PRIVATE KEY on krüpteeritud PKCS#8 ja vanem RSA PRIVATE KEY plokk, mis kannab Proc-Type: 4,ENCRYPTED on traditsiooniline vorm, ja mõlemad ootavad paroolifraasi. Krüpteerimata PRIVATE KEY plokk ei peaks seda üldse küsima. Käivitage parsimine selle kontoga, kellele fail kuulub, sest õiguste probleem annab teistsuguse ja palju vähem huvitava vea.

Kui võti on tõesti krüpteerimata ja klient küsib ikka, lõpetage krüptograafia vaatamine ja kontrollige, kas profiil nimetab askpass-faili, mida teenus saab veel lugeda.

Kontrollige, kas see build suudab selle dekrüpteerida

OpenSSL 3 jagas algoritmitoe pakkujateks ja hulk vanemaid šifreid asub nüüd legacy-pakkujas, mitte vaikimisi pakkujas. Nende šifritega krüpteeritud võti jääb kehtima, kuid ilma legacy-pakkujata laaditud teek ei suuda seda dekodeerida. Mõnel kliendil ilmneb see korduva viibana, teistel kõva tõrkena kohe pärast paroolifraasi.

Parsige sama võtit kaks korda sama binaariga: kõigepealt ainult vaikimisi pakkujaga, seejärel legacy ja vaikimisi mõlemad käsureal nõutuna. Kui teine katse õnnestub seal, kus esimene ebaõnnestus, põhineb diagnoos tõenditel, mitte uuenduse ajal. Kui mõlemad ebaõnnestuvad identselt, on paroolifraas vale või fail kahjustatud, ja ükski pakkuja säte ei paranda kumbagi.

Kontrollige kitsaimat võimalikku parandust

Eelistage kliendiga piiratud muudatust süsteemsele. Mõned 2.6 buildid aktsepteerivad profiilivalikut, mis laadib mõlemad pakkujad selle deemoniprotsessi jaoks, seega kontrollige direktiivi täpse versiooni käsiraamatust enne sellele lootmist; süsteemse openssl.cnf muutmine mõjutab seevastu iga OpenSSL-programmi hostis. Kitsam säte on ka palju lihtsam tagasi võtta, kui võti on ümber kodeeritud.

Ärge kustutage paroolifraasi, et viip kaoks. See muudab kaitstud mandaadi lihttekstifailiks ja muudab vaikselt iga varukoopia, koopia ja tugipaketi riski, milles see esineb. Oluline vahe on võtme vahel, mis vajab oma paroolifraasi, ja võtme vahel, mida see teek ei suuda dekodeerida.

Kontrollige teenuse konteksti ja kodeerige seejärel ümber

Kui võti on avatav, krüpteerige see uuesti kaasaegse algoritmiga et sõltuvus kaoks. Kirjutage uus fail kaasaegse šifriga, kontrollige, et see parsitakse, värskendage profiili ja hoidke vana koopiat ainult seni, kuni ühendus õnnestub. Ärge kunagi pange paroolifraasi käsureale, kus iga kohalik kasutaja saab selle protsesside loendist lugeda. Eemaldage vana fail alles pärast seda, kui uus on teenusekontolt ühenduse loonud, mitte ainult teie shellist.

Seejärel kontrollige üksust, mis klienti tegelikult käitab. Teie shellis loetav võti võib olla loetamatu teenusele, mis töötab teise konto all või karmistatud kodukataloogi sättega.

Kirjutage pakkuja säte profiili kõrvale ja hoidke kahe käsu test selle juures. Kui hilisem uuendus eemaldab legacy-pakkuja, käivitage see test uuesti, et näha, kas võti vajab seda endiselt või saab profiili möödahiilimisest välja võtta.

Viip on sümptom, millel on vähemalt kolm põhjust, ja ainult üks neist on puuduv paroolifraas.