OpenVPN na walang CA: paano vine-verify ng peer-fingerprint ang mga peer

Ang isang maliit na deployment ay dumudulog sa mga fingerprint dahil ang awtoridad ng sertipiko ay mukhang imprastrukturang walang may panahon na patakbuhin. Ang instinto ay makatuwiran, ngunit ang shortcut na kinukuha ng mga tao sa halip—pagkopya ng isang sikreto ng data channel sa dalawang dulo—ay hindi. Ang peer-fingerprint setup ay nagpapanatili ng TLS structure na buo: hawak pa rin ng bawat panig ang sarili nitong pribadong susi at sertipiko, at vine-verify pa rin ng bawat panig ang isa. Ang nagbabago ay kung saan nakaangkla ang verification: mula sa pinagkakatiwalaang issuer patungo sa maikling listahan ng mga naka-pin na digest. Dahil sinasaklaw ng digest ang buong sertipiko at hindi isang pangalan, ang pag-renew ay nagiging operasyong talagang kumakain ng oras.

Ano ang talagang pinangako ng fingerprint

Ang fingerprint ng sertipiko ay digest ng buong sertipikong naka-encode sa DER, hindi ng pampublikong susi nito at hindi ng pangalan ng subject nito. Kaya ang dalawang sertipikong may parehong pangalan at parehong susi ngunit magkaibang petsa ng validity ay may magkaibang fingerprint. Ito ang nagpapapino sa pinning, at ito rin ang nagpapagulo sa pag-renew. Ang pin ay hindi maaaring mangahulugang pagtitiwala sa isang susi sa pangkalahatan, dahil pinapangalanan nito ang isang artifact sa isang sandali ng buhay nito. Maaaring malaman ng kahit sino ang digest, at ang malaman ito ay walang pinapatunayan sa sarili nito.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Ang paghawak ng tugmang pribadong susi ang nagpapatunay na taglay ng peer ang sertipikong iyon, at ang digest ang paraan ng pagpapasya ng kabilang panig kung inaasahan nga nito ang sertipikong iyon. Ang paghihiwalay na ito ang dahilan kung bakit ang disenyong ito ay hindi ang lumang kaayusang pinagsasaluhang sikreto: ang pinagsasaluhang susi ay nagpapatotoo sa kahit sinong nakakaalam ng parehong bytes, samantalang ang pin ay nagpapatotoo sa isang sertipiko. Ang ibang device ay nakakakuha ng sarili nitong entry kaysa kopya ng parehong sikreto, na maliit na pagkakaiba sa mga file at malaki sa lawak ng pinsala.

Ang mapa ay pareho ang direksyon, hindi simetriko

Ang bawat endpoint ay nangangailangan ng dalawang bagay: ang sarili nitong pribadong susi kasama ang sertipiko, at isang pahayag tungkol sa kung aling mga sertipiko ng peer ang tatanggapin nito. Sa client, ang pahayag na iyon ay ang digest ng sertipiko ng server; sa server, ito ang listahan ng mga digest ng naka-rehistrong client. Isang opisyal na halimbawa para sa maliliit na setup para sa Community 2.6 ang nagpapakita ng kaayusan gamit ang peer-fingerprint, at sulit itong basahin bago piliin ang modelong ito ng tiwala para sa totoong deployment. Ang dalawang direksyon ay hindi isang baligtad na listahan, at hindi sila sabay na nabibigo.

Ang pagdaragdag ng device ay nag-e-edit ng listahan ng pinapayagan sa server, nang hindi kinokopya ang pribadong materyal ng umiiral na client at nang hindi ginagalaw ang susi ng server kahit saan. Ang dalawang direksyon ay nabibigo rin nang hiwalay, na kapaki-pakinabang sa diagnosis: ang panig na nagsasara ng handshake ang panig na hindi natupad ang inaasahan. Kung tinatanggihan ng client ang server, hindi tumutugma ang digest sa sertipikong iniharap. Kung tinatanggihan ng server ang client, wala ang digest ng client na iyon sa listahan, o naghaharap ang client ng ibang sertipiko kaysa sa naka-rehistro.

Pagpaparehistro: paano sumasali ang bagong device

Bumuo ng susi at sertipiko ng bagong device sa lugar kung saan maninirahan ang pribadong susi, pagkatapos ay ilipat lamang ang pampublikong artifact sa panig na kailangang magpin nito. Ilipat ang inaasahang digest sa channel na pinagkakatiwalaan mo na, at ihambing ang buong sertipiko kaysa sa pangalang mukhang pamilyar. Ang digest na kinopya mula sa parehong hindi na-verify na download ng sertipiko ay nagpapatunay lamang na ang dalawang file ay nagtutugma sa isa't isa. Ito ay pagsusuri ng pagkakapare-pareho at hindi ng pagkakakilanlan, at ito ang pinakatahimik na paraan ng paghina ng disenyong ito.

Sa server, ang pagdaragdag ng digest ay pagbabago sa configuration na dumadaan sa karaniwang manager at sinusundan ng muling pagkonekta. Kumpirmahin na kumokonekta ang bagong device at hindi na kumokonekta ang device na inalisan ng digest. Ang pagsusuring sumasaklaw lamang sa positibong kaso ay nag-iiwan sa listahan ng pinapayagan na hindi na-verify, at iyon mismo ang kalagayang mararanasan mo pagkalipas ng anim na buwan.

Ang pag-renew ang mamahaling sandali

Bawat sertipiko ay nag-e-expire, at ang bagong sertipiko ay may bagong digest kahit manatiling pareho ang susi at mga pangalan. Sa ilalim ng issuer, ang pag-renew ay transparent sa mga peer na nagtitiwala sa issuer na iyon; sa ilalim ng pinning, ito ay kaganapan ng pagpaparehistro para sa bawat peer na nagpipin ng sertipiko.

Planuhin ang pagkakasunod-sunod bago ang petsa ng pag-expire at hindi pagkatapos. Ipamahagi ang bagong digest sa mga panig na nagbe-verify nito, ilapat ang pagbabago, at pagkatapos lamang palitan ang sertipiko sa endpoint. Ang pagkakasunod-sunod na iyon ay hindi nag-iiwan ng window kung saan hindi magkasundo ang dalawang panig kung aling sertipiko ang kasalukuyan. Panatilihin ding nakasuri ang listahan mismo, dahil ang naka-pin na listahan ay naiipon ang mga entry para sa mga device na itinira ilang buwan na ang nakalipas. Bawat laos na entry ay pagkakakilanlang nagpapatotoo pa rin kung nabubuhay ang susi nito, kaya ang pag-alis ng isa ay aksyong pangseguridad at hindi paglilinis.

Ano ang hindi pinagpapasyahan ng mapa ng tiwala

Ang authentication ay isang layer, at ang naka-pin na mapa ay walang sinasabi tungkol sa pool ng address, mga itinutulak na ruta, MTU ng landas o patakaran ng firewall. Nananatili silang hiwalay na configuration na may hiwalay na paraan ng pagpalya. Ang tunnel na nagpapatotoo at walang dumaraang trapiko ay ibang imbestigasyon kaysa sa isang hindi kailanman bumabangon.

Ang mapa rin ay hindi lumalaki nang walang hanggan, at ang PKI na batay sa issuer ang pinagtatapusan ng mas malalaking deployment. Ang kagustuhang iyon ay tungkol sa operasyon at hindi sa cryptography, dahil ang pagdaragdag at pag-alis ng pagkakakilanlan sa pamamagitan ng isang awtoridad ay mas mura kaysa sa pag-e-edit ng listahan sa bawat peer habang lumalaki ang fleet. Kung saan hindi sinusuportahan ng implementasyon ng client ang opsyon, ang sagot ay isang modelong ng tiwala na tugma anumang idinodokumento ng client na iyon, o isang sinusuportahang kapalit. Ang pagpigil sa babala sa verification ay hindi nagdadagdag ng suportang iyon, at ang buong halaga ng disenyo ay nagaganap pa rin ang verification.