OpenVPN-ŝlosila prompto post OpenSSL 3: kontrolu la provizanton

Neniu tuŝis la profilon, tamen la sama kliento nun postulas pasfrazon por la privata ŝlosilo ĉiufoje kiam ĝi startas. Kiam tiu ŝanĝo okazas ene de kelkaj tagoj post ĝisdatigo de la distribuo, la ĝisdatigo estas la verŝajna kaŭzo: OpenSSL 3 reorganizis sian subtenon de algoritmoj, kaj ŝlosilo, kiun la malnova biblioteko senprobleme legis, povas fariĝi nelegebla sen ŝanĝo de eĉ unu bajto. Plenumu la kontrolojn laŭ ordo, ĉar du el ili aspektas identaj se vi rigardas nur la prompton.

La unua demando estas ĉu la ŝlosilo estas ĉifrita, kaj la dua estas ĉu ĉi tiu konstruo povas malĉifri ĝin. Ŝanĝoj de agordo nur sencas post kiam ambaŭ respondoj estas konataj.

Kontrolu ĉu la ŝlosilo estas ĉifrita

Legu la unuan linion de la dosiero kaj poste lasu la bibliotekon analizi ĝin, ĉar dosiernomo pruvas nenion. PEM-bloko etikedita ENCRYPTED PRIVATE KEY estas ĉifrita PKCS#8, kaj pli malnova RSA PRIVATE KEY bloko portanta Proc-Type: 4,ENCRYPTED estas la tradicia formo, kaj ambaŭ atendas pasfrazon. Neĉifrita PRIVATE KEY bloko tute ne petu pri ĝi. Rulu la analizon kiel la konto, kiu posedas la dosieron, ĉar permesa problemo produktas alian kaj multe malpli interesan eraron.

Se la ŝlosilo vere estas neĉifrita kaj la kliento ankoraŭ demandas, ĉesu rigardi kriptografion kaj kontrolu ĉu la profilo nomas askpass-dosieron, kiun la servo ankoraŭ povas legi.

Kontrolu ĉu ĉi tiu konstruo povas malĉifri ĝin

OpenSSL 3 dividis sian subtenon de algoritmoj en provizantojn, kaj aro da pli malnovaj ĉifroj nun sidas en la legacy-provizanto anstataŭ en la defaŭlta. Ŝlosilo ĉifrita per unu el tiuj ĉifroj restas valida, sed biblioteko ŝargita sen la legacy-provizanto ne povas malĉifri ĝin. Ĉe iuj klientoj tio aperas kiel prompto, kiu ripetiĝas, ĉe aliaj kiel dura malsukceso tuj post la pasfrazo.

Analizu la saman ŝlosilon dufoje per la sama duuma dosiero: unue nur kun la defaŭlta provizanto, poste kun legacy kaj defaŭlta ambaŭ petitaj en la komandlinio. Se la dua provo sukcesas tie, kie la unua malsukcesis, la diagnozo baziĝas sur pruvoj anstataŭ sur la tempo de ĝisdatigo. Se ambaŭ malsukcesas idente, la pasfrazo estas malĝusta aŭ la dosiero estas difektita, kaj neniu provizanta agordo riparas iun el la du.

Kontrolu la plej mallarĝan disponeblan riparon

Preferu ŝanĝon limigitan al la kliento anstataŭ unu por la tuta sistemo. Iuj konstruoj 2.6 akceptas profilan opcion, kiu ŝargas ambaŭ provizantojn por la procezo de tiu demono, do konfirmu la direktivon en la manlibro por via preciza versio antaŭ ol fidi ĝin; redakti la sisteman openssl.cnf anstataŭe efikas al ĉiu OpenSSL-programo sur la gastiganto. La pli mallarĝa agordo ankaŭ estas multe pli facile malfarebla post kiam la ŝlosilo estas rekodita.

Ne forigu la pasfrazon por ke la prompto malaperu. Tio transformas protektitan akreditilon en klartekstan dosieron kaj silente ŝanĝas la riskon de ĉiu savkopio, kopio kaj subtena pakaĵo, en kiu ĝi aperas. La grava distingo estas inter ŝlosilo, kiu bezonas sian pasfrazon, kaj ŝlosilo, kiun ĉi tiu biblioteko ne povas malĉifri.

Kontrolu la servan kuntekston, poste rekodu

Post kiam la ŝlosilo povas esti malŝlosita, reĉifru ĝin per aktuala algoritmo por ke la dependeco malaperu. Skribu la novan dosieron per moderna ĉifro, kontrolu ke ĝi analiziĝas, ĝisdatigu la profilon, kaj konservu la malnovan kopion nur ĝis konekto sukcesos. Neniam metu la pasfrazon en komandlinion, kie ajna loka uzanto povas legi ĝin el la proceza listo. Forigu la malnovan dosieron nur post kiam la nova konektiĝis el la serva konto, ne nur el via ŝelo.

Tiam kontrolu la unuon, kiu efektive rulas la klienton. Ŝlosilo legebla en via ŝelo povas esti nelegebla por servo ruliĝanta sub alia konto aŭ kun malmoligita hejma dosieruja agordo.

Notu la provizantan agordon apud la profilo kaj tenu la du-komandan teston kun ĝi. Kiam posta ĝisdatigo forigos la legacy-provizanton, rerulu tiun teston por vidi ĉu la ŝlosilo ankoraŭ bezonas ĝin aŭ ĉu la profilo povas esti eltirita el la provizora solvo.

Prompto estas simptomo kun almenaŭ tri kaŭzoj, kaj nur unu el ili estas mankanta pasfrazo.