OpenVPN tls-crypt-v2: ginagawa ng susi ng kliyente at ng nakabalot na blob
Ang isang profile ng tls-crypt-v2 ay may kontrol na susi ng kliyente at nakabalot na kopya na tanging server lang ang makakabukas. Panatilihing hiwalay ang bawat bagay at bawat hakbang ng pagtatanggal.
Ang pag-paste ng profile ng tls-crypt-v2 sa isang ticket ay mukhang walang pinsala hanggang bilangin mo kung ano ang laman ng file. Ang susi ng control channel ng kliyente ay katabi ng naka-encrypt na kopya ng parehong susi, at ang ikatlong bagay, ang pambalot na susi, ay hindi kailanman lumalabas sa server na tumatanggap. Ang tatlong ito ay sumasagot sa magkakaibang tanong tungkol sa pag-iingat, pagbabahagi at pagtatanggal. Ang paghihiwalay sa kanila ay nilulutas ang karamihan ng mga pagtatalo sa patakaran bago pa magsimula.
Ano talaga ang laman ng profile
Ang kalahating kliyente ng tls-crypt-v2 ay isang susi at isang nakabalot na kopya nito. Ginagamit ng kliyente ang payak na susi para sa proteksyon ng control channel at ibinibigay sa server ang nakabalot na kopya sa panahon ng pag-setup, kaya nakukuha muli ng server ang parehong susi nang hindi nag-iimbak ng kopya sa malinaw na teksto para sa bawat kliyente. Ang pambalot na susi ang nagpapangyari sa pagkuha muli na iyon at pag-aari lamang ng panig na tumatanggap. Lahat ng nasa ibaba ay nagmumula sa kung saan naninirahan ang tatlong bagay na iyon.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Basahin ang talahanayan ayon sa pag-iingat, hindi ayon sa pangalan, at ang mga kahihinatnan ay kusang lumilitaw. Ang pagkawala ng pambalot na susi ang mamahaling pangyayari, dahil walang anuman sa profile ang makakabuo muli nito at ang tapat na pagbawi ay muling pag-isyu ng grupo. Ang na-leak na profile ay mas mura ngunit mas karaniwan, dahil ang mga tao ay nagpa-paste ng profile sa mga ticket na naniniwala na ginagawang ligtas ng nakabalot na kopya ang file para ibahagi. Ang dalawang pagkabigo ay nangangailangan ng magkaibang tugon, at iyon ang dahilan kung bakit hiwalay ang mga bagay.
Bakit ang nakabalot na kopya ay hindi ang buong kuwento
Dinadala ng profile ang magagamit na materyal ng kliyente kasama ang nakabalot na katapat nito, kaya ang pagprotekta sa kopya para sa server ay walang sinasabi tungkol sa pagprotekta sa file. Ang blob ay ligtas ihatid at hindi ligtas ilathala. Ang metadata sa loob nito ay nakikita ng sinumang tumatanggap ng blob, kabilang ang sinumang babasa ng ticket kung saan ito na-paste.
Ituring ang profile bilang kredensyal, hindi bilang halimbawa ng configuration. Ang na-leak na file ay nagbibigay sa may hawak nito ng gumaganang pagkakakilanlan ng kliyente hanggang sa ihinto ng server ang pagtanggap sa pagkakakilanlan na iyon, at walang ginagawa ang pagbalot tungkol sa bintanang iyon. Mag-isyu ng isang profile bawat kliyente upang manatiling desisyon sa isang file ang pag-withdraw, at i-backup ang pambalot na susi nang hiwalay sa configuration ng server na pinapagana nito. Wala sa dalawang ugali ang nag-aayos ng komprometidong profile, ngunit parehong nagpapasya kung gaano kabilis mapipigilan ang susunod.
Saan nakaupo ang hook ng verification sa handshake
Tumakbo ang hook ng verification bago ilantad ang TLS stack, at ang trabaho nito ay siyasatin ang metadata na dala sa nakabalot na blob. Natatanggap nito ang metadata na iyon at isang maliit, dokumentadong kapaligiran, at mas kakaunti ang mapagtatrabahuhan nito kaysa sa isang hook ng authentication. Ang pag-akala na nakikita nito ang mga username, estado ng session o mga variable ng plugin ang karaniwang paraan ng masamang pagsulat ng hook na ito. Basahin ang sariling seksyon ng manwal ng hook sa halip na humiram ng mga inaasahan mula sa ibang hook.
Ang exit status nito ang desisyon: tinatanggihan ng resultang hindi zero ang kliyente at hinahayaang magpatuloy ng resultang zero ang handshake. Kaya dapat sabihin ng patakaran kung ano ang nangyayari kapag kulang ang metadata, hindi ito ma-parse o hindi inaasahan. Isulat muna ang daan ng pagtanggi, pagkatapos ay magpasya kung aling mga halaga ang katanggap-tanggap.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shAng dalawang linyang iyon ang ibabaw ng patakaran sa server: pinangalanan ng isa ang pambalot na susi, pinangalanan ng isa pa ang programang humuhusga sa bawat kliyente. Lahat ng kawili-wili ay naninirahan sa script, na karapat-dapat sa version control at sa parehong pagsusuri tulad ng anumang iba pang tuntunin ng access.
Hiwalay na nagretiro ang account, certificate at control key
Ang maagang pagtanggap ng control channel ay hindi authentication, dahil nangyayari ito bago ang pagsusuri ng pagkakakilanlan ng TLS at bago ang anumang awtorisasyon ng account. Ang pag-disable ng account, pag-revoke ng certificate at pagtanggi sa control key ng kliyente ay tatlong aksyon na may tatlong mekanismo. Ang deployment na gagawin lamang ang isa sa mga ito ay may puwang, hindi patakaran. Maingat na pagtugmain ang tatlo, at itala kung aling hakbang ang gumagamit ng aling awtoridad.
Ang oras ang ikalawang pagkakaiba. Ang binagong listahan ng pagtanggap ay nalalapat sa mga bagong handshake, habang ang mga session na naitatag na ay patuloy na tumatakbo hanggang may magtapos sa kanila. Ang pagbilang ng mga entry sa bagong listahan bilang patunay na natapos na ang lumang session ay kung paano nananatiling konektado ang tinanggal na kliyente nang maraming oras.
Ang mga hindi naitugmang awtoridad ay nag-iiwan ng dalawang butas na madaling mahanap sa praktika. Maaaring naka-disable ang account habang bukas pa rin ng control key nito ang isang handshake, at maaaring na-revoke ang certificate habang tinatanggap pa rin ng patakaran ng metadata ang parehong kliyente. Pareho silang parehong pagkakamali sa magkaibang lugar, dahil itinuring ng operator ang isang listahan bilang buong awtoridad. Ilagay ang tatlong listahan nang magkatabi sa oras ng pagtatanggal at makikita ang pagkakamali.
Pag-isyu at pag-withdraw ng profile
Ang pag-isyu ang madaling kalahati: likhain ang susi ng kliyente sa panig na tumatanggap, ibigay ang profile sa eksaktong isang may-ari, panatilihing limitado ang materyal ng pagbalot, at patakbuhin ang parehong programa ng verification sa bawat server na tumatanggap. Ang murang pagpasok ay katangian ng buong grupo, hindi ng pinakabagong host. Ang ikalawang server na may mas lumang o mas maluwag na script ay tahimik na nagiging pinakamahinang landas sa deployment.
Ang pag-withdraw ay nangangailangan ng tatlong hakbang sa sinadyang pagkakasunod-sunod. Tanggihan ang kliyente sa hook ng verification upang mabigo ang mga bagong handshake, i-revoke ang certificate nito kung gumagamit ng PKI, at i-disable ang account upang walang maawtorisa ang susunod na awtorisasyon. Pagkatapos, tapusin ang mga session na pinahintulutan ng lumang pagtanggap, dahil hindi nila mapapansin ang alinman sa tatlo. Sanayin ang pagkakasunod-sunod sa isang kliyenteng kayang mong sirain.
Ang metadata sa isang profile ay input sa patakarang iyon, hindi patunay na mayroon nang kontrol sa access. Inilalarawan ng dokumento ng disenyo ng OpenVPN 2.6 ang mga bagay at ang hangganang iginuhit nila, habang ang pagpapatupad ay nananatili sa operator.