Mga pangalan ng SHA1 digest sa OpenSSL: ano ang ibig sabihin ng lumang listahan

Ang mga lumang listahan ng digest ay binabasa na parang transkrip ng mga desisyong cryptographic, at hindi sila ganoon. Ang mga pangalang tulad ng SHA1, DSA-SHA1-old o RSA-SHA1-2 ay magkakatabi sa lumang OpenSSL build dahil nagrehistro ang aklatan ng ilang entry point sa paligid ng kaugnay na hash machinery. Ang label na RSA o DSA sa listahang iyon OpenVPN ay walang sinasabi tungkol sa ginawa nito sa isang packet. Ang binabasa mo ay imbentaryo ng aklatan, hindi rekord ng isang session.

Tatlong bagay ang dapat paghiwalayin bago magkaroon ng kahulugan ang anumang konklusyon: ang nakarehistrong pangalan, ang pagkalkula ng digest sa ilalim nito at ang operasyong gumagamit nito.

Ang pagrerehistro ay isang interface, hindi rating ng lakas

Sa OpenSSL 1.0.2, pinag-uugnay ng talahanayan ng pagrerehistro ng digest ang mga pangalan, alias at implementasyon sa isang file. Ang lumang DSS1 descriptor ang pinakamalinaw na kaso: iniuulat nito ang haba ng output ng SHA-1 at tinatawag ang finalization routine ng SHA-1 habang may dalang pangalang nagmumungkahi ng ganap na ibang algorithm. Kaya ang dagdag na titik sa isang pagrerehistro ay hindi nangangahulugan ng ibang hash, mas mahabang output o bagong antas ng seguridad.

Pinapanatili ng parehong source ang mga relasyon ng alias para sa mas lumang tumatawag, na nagpapaliwanag kung bakit parang puno ang isang listahan. Ito ay dokumentasyon ng pagiging compatible, hindi pangako na ang kasalukuyang provider ng OpenSSL ay magpapakita ng magkatulad na pangalan.

Ang mga pangalan ng paglagda ay hindi lumilikha ng lagda

Maaaring itali ng isang signing framework ang isang digest sa interface ng ibang algorithm upang patuloy na makompile ang mga umiiral na tumatawag. Ang tunay na public-key na lagda ay nangangailangan ng susi at ng hakbang sa paglagda na gumagamit nito, at wala sa dalawa ang ibinibigay ng pangalan sa isang menu. Ang digest entry na may lasa ng RSA ay pangalang maaaring gamitin ng tumatawag, hindi patunay na bawat VPN packet ay may dalang RSA signature.

Sa hakbang na ito nagiging alamat ang mas lumang mga sulatin. Kung kailangan mong malaman kung paano na-authenticate ang mga packet, hanapin ang opsyong pumili ng mekanismo at basahin ang ginagawa nito sa bersyong aktwal mong pinapatakbo. Ang manual page na kasama ng release na iyon ang tanging paglalarawang tumutugma sa programang nasa harap mo. Inilalarawan ng mga archived guide ang release na pinagsulatan nila, at maaaring ilang naming convention itong nasa likod.

Hanapin ang opsyong gumamit ng pangalan

Sa kaso ng packet authentication na dokumentado ng OpenVPN 2.6, pumipili ang auth ng digest na ginagamit ng HMAC, isang keyed na konstruksyon ng pag-authenticate ng mensahe sa halip na lagda ng sertipiko. Ang algorithm ng paglagda ng TLS certificate ay hiwalay na katangian ng handshake.

Sa AEAD data cipher, hindi na nalalapat ang hiwalay na setting na auth sa data channel, habang ang papel nito para sa tls-auth ay nananatiling hiwalay na tanong. Kaya hindi masasabi ng listahan ng digest kung aling hash ang nagproteka sa kasalukuyang mga packet, aling TLS suite ang napagkasunduan o paano nilagdaan ang sertipiko ng peer. Tanging ang epektibong configuration kasama ang bersyon ang makakasagot, at para lamang sa koneksyong nasa harap mo.

Itala ang talagang mayroon ka

Itala ang bersyon ng OpenVPN, ang naka-link na crypto library, ang eksaktong mga opsyon sa profile at ang resulta ng totoong koneksyon. Sinasagot ng set na iyon ang mga tanong na hindi kayang sagutin ng screenshot ng digest menu, at nakakaligtas ito sa susunod na upgrade dahil binabanggit nito ang mga bersyon at hindi ang mga impresyon.

Higit sa lahat, huwag pumili ng lumang alias dahil mas malakas o mas tiyak ang tunog ng pangalan nito. Piliin ang sinusuportahang patakaran para sa buong koneksyon, at ituring ang mga lumang pangalan na rekord kung paano ipinakita ng aklatan ang sarili nito noon.