Kërkesa për çelësin OpenVPN pas OpenSSL 3: kontrolloni ofruesin

Askush nuk e preku profilin, por i njëjti klient tani kërkon një frazë të fshehtë për çelësin privat në çdo nisje. Kur ky ndryshim ndodh brenda disa ditësh pas një përditësimi të shpërndarjes, përditësimi është shkaku i mundshëm: OpenSSL 3 riorganizoi mbështetjen e algoritmeve, dhe një çelës që biblioteka e vjetër e lexonte pa problem mund të bëhet i palexueshëm pa ndryshuar asnjë bajt. Kryeni kontrollet sipas radhës, sepse dy prej tyre duken identike nëse shikoni vetëm kërkesën.

Pyetja e parë është nëse çelësi është i kriptuar, dhe e dyta nëse ky build mund ta dekriptojë. Ndryshimet e konfigurimit kanë kuptim vetëm pasi të njihen të dyja përgjigjet.

Kontrolloni nëse çelësi është i kriptuar

Lexoni rreshtin e parë të skedarit dhe më pas lëreni bibliotekën ta analizojë, sepse emri i skedarit nuk provon asgjë. Një bllok PEM me etiketën ENCRYPTED PRIVATE KEY është PKCS#8 i kriptuar, dhe një bllok RSA PRIVATE KEY më i vjetër që mban Proc-Type: 4,ENCRYPTED është forma tradicionale, dhe të dy presin një frazë të fshehtë. Një bllok PRIVATE KEY i pakriptuar nuk duhet të kërkojë fare. Ekzekutoni analizën me llogarinë që zotëron skedarin, sepse një problem leje jep një gabim tjetër dhe shumë më pak interesant.

Nëse çelësi me të vërtetë nuk është i kriptuar dhe klienti vazhdon të pyesë, ndaloni së shikuari kriptografinë dhe kontrolloni nëse profili përmend një skedar askpass që shërbimi ende mund ta lexojë.

Kontrolloni nëse ky build mund ta dekriptojë

OpenSSL 3 e ndau mbështetjen e algoritmeve në ofrues, dhe një grup shifrash më të vjetër tani qëndron te ofruesi legacy në vend të atij të parazgjedhur. Një çelës i kriptuar me një prej atyre shifrave mbetet i vlefshëm, por një bibliotekë e ngarkuar pa ofruesin legacy nuk mund ta dekodojë. Te disa klientë kjo shfaqet si një kërkesë që përsëritet, te të tjerë si një dështim i fortë menjëherë pas frazës së fshehtë.

Analizoni të njëjtin çelës dy herë me të njëjtin binar: së pari vetëm me ofruesin e parazgjedhur, më pas me legacy dhe të parazgjedhurin të kërkuar të dy në rreshtin e komandës. Nëse përpjekja e dytë ka sukses aty ku e para dështoi, diagnoza mbështetet në prova dhe jo në kohën e përditësimit. Nëse të dyja dështojnë njësoj, fraza e fshehtë është e gabuar ose skedari është dëmtuar, dhe asnjë rregullim ofruesi nuk rregullon asnjërën.

Kontrolloni rregullimin më të ngushtë të disponueshëm

Preferoni një ndryshim të kufizuar te klienti sesa një në nivel sistemi. Disa build-e 2.6 pranojnë një opsion profili që ngarkon të dy ofruesit për procesin e atij daemon, prandaj verifikoni direktivën në manualin për versionin tuaj të saktë përpara se të mbështeteni tek ai; redaktimi i openssl.cnf të sistemit në vend të kësaj prek çdo program OpenSSL në host. Cilësimi më i ngushtë është gjithashtu shumë më i lehtë për t’u kthyer pasi çelësi të rikodohet.

Mos e fshini frazën e fshehtë që të zhduket kërkesa. Kjo e kthen një kredencial të mbrojtur në një skedar teksti të thjeshtë dhe ndryshon në heshtje rrezikun e çdo kopje rezervë, kopje dhe pakete mbështetjeje ku shfaqet. Dallimi që ka rëndësi është midis një çelësi që ka nevojë për frazën e tij të fshehtë dhe një çelësi që kjo bibliotekë nuk mund ta dekodojë.

Kontrolloni kontekstin e shërbimit, më pas rikodojeni

Pasi çelësi mund të hapet, rikriptojeni me një algoritëm aktual në mënyrë që varësia të zhduket. Shkruani skedarin e ri me një shifër moderne, verifikoni që analizohet, përditësoni profilin dhe mbani kopjen e vjetër vetëm derisa një lidhje të ketë sukses. Kurrë mos e vendosni frazën e fshehtë në një rresht komande, ku çdo përdorues lokal mund ta lexojë nga lista e proceseve. Hiqni skedarin e vjetër vetëm pasi ai i ri të jetë lidhur nga llogaria e shërbimit, jo vetëm nga shell-i juaj.

Më pas kontrolloni njësinë që ekzekuton vërtet klientin. Një çelës i lexueshëm në shell-in tuaj mund të jetë i palexueshëm për një shërbim që ekzekutohet nën një llogari tjetër ose me një cilësim të forcuar të drejtorisë shtëpiake.

Regjistroni cilësimin e ofruesit pranë profilit dhe mbani testin me dy komanda bashkë me të. Kur një përditësim i mëvonshëm heq ofruesin legacy, ekzekutoni përsëri atë test për të parë nëse çelësi ka ende nevojë për të ose nëse profili mund të hiqet nga kjo zgjidhje e përkohshme.

Një kërkesë është një simptomë me të paktën tre shkaqe, dhe vetëm një prej tyre është një frazë e fshehtë që mungon.