Certipiko ng VPN na pinirmahan sa sarili: ano ang ibig sabihin at ano ang pinagkakatiwalaan nito

Dalawang paniniwala ang gumagawa ng pinakamalaking pinsala dito: na ang certipiko ng VPN na pinirmahan sa sarili ay nangangahulugang hindi naka-encrypt ang tunel, at na ang pag-install ng anumang hiniling ng kliyente ng VPN ay nakakaapekto lamang sa VPN. Ni isa ay hindi nakakaligtas sa pakikipag-ugnayan sa totoong deployment. Ang certipikong pinirmahan sa sarili naglalarawan ng ugnayan ng lagda, hindi ng hatol sa seguridad, at ang saklaw ng tiwalang idinadagdag mo ay nakadepende sa kung aling imbakan ito mapupunta. Nakita ko ang isang helpdesk na nag-import ng root ng provider sa isang Windows machine para patahimikin ang isang babala, pagkatapos ay gumugol ng isang hapon sa pagpapaliwanag kung bakit tumigil ang browser sa pagrereklamo tungkol sa isang walang kaugnayang portal. Ang dalawang kalahati ng tanong na ito ay magkasama, kaya ituring silang isa.

Ang certipiko ay hindi imbakan ng tiwala

Ang file na inihaharap ng server ay nagdadala ng pampublikong susi, pangalan ng paksa, pangalan ng nagbigay, mga petsa ng bisa at mga extension. Ang pinirmahan sa sarili ay nangangahulugang ang paksa at ang nagbigay ay iisang entidad at ang lagda ay bine-verify gamit ang sariling susi ng certipiko. Wala sa kahulugang iyon ang nagsasabing mahina ang koneksyon, at wala ring nagsasabing tatanggapin ito ng kliyente.

Ang pagtanggap ay nagmumula sa ibang lugar: isang file ng CA na itinuturo mo sa kliyente, isang fingerprint na ihinahambing mo sa kamay, o isang root na nakaupo na sa imbakan na binabasa ng kliyente. Ang deployment ay maaaring ganap na maayos habang ang certipiko nito ay babagsak sa bawat pampublikong pagsusuri. openssl verify laban sa system bundle ay mag-uulat ng hindi kilalang nagbigay, at ang ulat na iyon ay tama, hindi depekto.

Ang opsyon na ca ng OpenVPN ang pinakamalinaw na kaso ng tiwalang nakakulong sa app. Pinangalanan ng file na iyon ang mga anchor na tatanggapin ng kliyente, at maaaring maglaman ito ng isang pribadong CA o, sa maliit na deployment, ang sariling certipiko ng server na pinirmahan sa sarili. Tumatanggap din ang bersyon 2.6 ng --peer-fingerprint para i-pin ang fingerprint ng SHA-256 sa halip na mamahagi ng file ng CA. Ang WireGuard ay mas malayo pa: wala itong certipiko, isang static na pampublikong susi lamang bawat peer, kaya hindi ito inaangkop ng tanong tungkol sa pinirmahan sa sarili.

Kung saan mo ini-install ang tiwala ang nagtatakda kung sino ang magmamana nito

Ilagay ang parehong certipiko sa tatlong lugar at makakakuha ka ng tatlong magkaibang radius ng pagsabog. Ang bundle na binabasa lamang ng kliyente ng VPN ay nakakaapekto sa kliyenteng iyon. Ang root sa imbakan ng operating system ay nakakaapekto sa bawat programang sumasangguni sa imbakang iyon. Ang browser na may sariling database ng tiwala ay maaaring huwag pansinin ang dalawa, kaya nga may babalang nakakaligtas sa isang import na mukhang gumana.

Sa Debian o Ubuntu, ang paglalagay ng file sa /usr/local/share/ca-certificates/ at pagpapatakbo ng update-ca-certificates ay nagbabago ng bundle sa buong sistema. Sa Windows, ang certutil -addstore -f Root ay nagsusulat sa imbakan ng makina at nangangailangan ng elevated prompt, samantalang ang pagdaragdag ng -user ay tumututok sa imbakan ng kasalukuyang gumagamit; hindi mapagpapalit ang dalawa. Ang Firefox ay may sariling database ng NSS, kaya ang import sa antas ng OS ay maaaring hindi kailanman lumitaw doon.

Mahalaga ang saklaw dahil sa kayang gawin ng isang awtoridad. Ang nagbibigay na CA ay makakapirma para sa mga pangalang wala itong kaugnayan, kaya ang anumang nagtitiwala sa imbakang iyon ay tatanggap ng mga lagdang iyon. Hindi kayang gawin iyon ng isang naka-pin na dahon; eksaktong isang pagkakakilanlan ng peer ang pinapatotohanan nito. Kung ang layunin ay mapakonekta ang isang VPN, naaabot ito ng CA na nakakulong sa app o ng naka-pin na dahon, samantalang ang root sa buong makina ay mas malaking konsesyon kaysa sa hinihingi ng sintomas.

Nag-e-encrypt ka pa rin nang walang pampublikong CA

Ang handshake ng TLS ay kumukuha ng mga susi ng session kahit na ang certipiko ng peer ay kumakawing sa isang bagay na pinagkakatiwalaan mo na o hindi. Ang pinirmahan sa sarili ay hindi nangangahulugang plaintext, at hindi rin nangangahulugang nababasa ang trapiko habang nasa biyahe. Ang ibig sabihin ay walang kadahilanang pasubali ang kliyente na maniwala na ang susi ay pag-aari ng server na hiniling nito.

Sa puwang na iyon nakatira ang totoong mga pag-atake. Ang kliyenteng naka-configure na tumanggap ng kahit anong certipiko, sa pamamagitan man ng naka-disable na setting ng verification o ng pindutang tiwala-kahit-ganoon na pinindot isang beses at nakalimutan, ay masayang mag-e-encrypt sa sinumang sasagot. Ang interception ay nangyayari sa hakbang ng authentication, bago gumalaw ang data ng application. Ang encryption na walang tsek ng pagkakakilanlan ay naglalayo sa isang pasibong tagamasid at wala nang halos ginagawa.

Ang pagtitiwala sa nagbigay ay hindi lumalaktaw sa tsek ng pangalan

Ang validation ng chain, pagtutugma ng pangalan at layunin ng certipiko ay magkakahiwalay na desisyon. Maaaring wasto ang chain habang mali ang pangalan, at maaaring tumugma ang pangalan habang ang certipiko ay inilabas para sa ibang papel. Tinutukoy ng RFC 5280 ang mga field na nagdadala ng mga hadlang na iyon, at kung gaano kahigpit ipinapatupad ng kliyente ang mga ito ay usapin ng bawat application.

Ginagawang nakikita ng OpenVPN ang paghahati. Ini-pin ng verify-x509-name ang inaasahang paksa sa pamamagitan ng pagtutugma ng name, name-prefix o subject. Hinihingi ng remote-cert-tls server na magamit ang certipiko ng peer bilang certipiko ng server, na tumatanggihan ng certipikong pang-kliyente lamang kahit pinagkakatiwalaan ang nagbigay. Wala sa dalawang setting ang napapalitan ng pagpapadala ng file ng CA.

Suriin ang certipiko bago magpasya ng kahit ano:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ay nagpapakita kung sino ang naglabas, para sa aling mga pangalan at hanggang kailan.
• openssl verify -CAfile ca.crt server.crt ay sumusuri kung talagang bine-validate ng chain na ipapadala mo ang dahon.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error ay gumagana para sa mga TLS endpoint tulad ng web portal; ang protokol ng OpenVPN sa 1194 ay hindi ordinaryong TLS stream, kaya hindi iyon naaangkop doon.

Ang certipikong may petsang lagpas na, walang subjectAltName para sa pangalang kinokonektahan mo, o walang paggamit ng serverAuth ay nabibigo kahit gaano kaingat na na-install ang anchor.

Limang pagsusuri bago tumanggap ng isa

Ihambing ang fingerprint sa isang channel na hindi ang koneksyong sinusubukan mong ayusin: isang console, isang installer na mayroon ka na, isang pinirmahang configuration file. Ang openssl x509 -in server.crt -noout -fingerprint -sha256 sa server at ang parehong halaga sa log ng kliyente ay sapat na para malaman na iisang bagay ang tinitingnan mo.

Pagkatapos, magpasya kung ano ang ini-install mo: isang dahon, o isang awtoridad na makakagawa pa ng marami. Pagkatapos ay magpasya kung saan ito pupunta, at pangalanan ang mga application na bumabasa ng imbakang iyon. Isulat ang landas ng pag-alis habang naaalala mo pa ito, dahil ang magtiwala-at-tumuloy ang paraan para maging permanente ang isang pansamantalang import.

Sa huli, planuhin ang pagbabago. Ang naka-pin na certipiko o fingerprint ay dapat i-update sa parehong pinagkakatiwalaang channel kapag umiikot ang certipiko, at ang pribadong CA ay may sariling ikot ng buhay ng paglabas at pagpapawalang-bisa. Kung tumagas ang pribadong susi, walang naaayos ang muling pagtitiwala sa kopya ng parehong certipiko; kailangang palitan ang pagkakakilanlan.

Kung ang isang babala ay nakaligtas sa lahat ng limang pagsusuri, ang kapaki-pakinabang na tanong ay hindi kung aling pindutan ang nagpapatahimik dito kundi kung aling imbakan ang talagang binabasa ng kliyente at saan nagmula ang root na iyon. Sagutin iyon, at ang import na gagawin mo ay magiging desisyon sa halip na reaksiyon.