OpenVPN tls-crypt-v2: kion faras la klienta ŝlosilo kaj la volvita blob
Profilo tls-crypt-v2 enhavas klientan regan ŝlosilon kaj volvitan kopion, kiun nur la servilo povas malfermi. Tenu ĉiun objekton kaj ĉiun retiriĝan paŝon aparte.
Enigi profilon tls-crypt-v2 en bileton ŝajnas sendanĝere ĝis vi kalkulos, kion enhavas la dosiero. La rega kanala ŝlosilo de la kliento staras apud ĉifrita kopio de tiu sama ŝlosilo, kaj tria objekto, la volva ŝlosilo, neniam forlasas la akceptantan servilon. Tiuj tri respondas al malsamaj demandoj pri gardado, kundivido kaj retiriĝo. Ilia apartigo solvas la plej multajn politikajn disputojn antaŭ ol ili komenciĝas.
Kion la profilo efektive enhavas
La klienta duono de tls-crypt-v2 estas ŝlosilo plus volvita kopio de ĝi. La kliento uzas la ordinaran ŝlosilon por protekto de la rega kanalo kaj transdonas la volvitan kopion al la servilo dum agordo, tiel ke la servilo rekuperas la saman ŝlosilon sen konservi klartekstan kopion por ĉiu kliento. La volva ŝlosilo ebligas tiun rekuperon kaj apartenas nur al la akceptanta flanko. Ĉio sube sekvas el tio, kie tiuj tri objektoj loĝas.
| 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 |
Legu la tabelon laŭ gardado anstataŭ laŭ nomo, kaj la sekvoj mem evidentiĝas. Perdi la volvan ŝlosilon estas la multekosta okazaĵo, ĉar nenio en profilo povas rekonstrui ĝin kaj la honesta riparo estas reeldoni la grupon. Likita profilo estas pli malmultekosta sed multe pli ofta, ĉar profilon en biletojn enigas homoj, kiuj kredas, ke la volvita kopio faras la dosieron sekura por kundivido. La du fiaskoj bezonas malsamajn respondojn, kaj tial la objektoj teniĝas aparte.
Kial la volvita kopio ne estas la tuta rakonto
Profilo portas la uzeblan klientan materialon kune kun ĝia volvita pandanto, do protekti la kopion por la servilo diras nenion pri protektado de la dosiero. La blob estas sekura por transdoni kaj nesekura por publikigi. La metadatenoj interne estas videblaj al ĉiu, kiu ricevas la blob, inkluzive de iu, kiu poste legas la bileton, en kiun ĝi estis enigita.
Traktu profilon kiel akreditilon, ne kiel ekzemplon de agordo. Likita dosiero donas al sia posedanto funkciantan klientan identecon ĝis la servilo ĉesos akcepti tiun identecon, kaj la volvado faras nenion pri tiu fenestro. Eldonu unu profilon por ĉiu kliento por ke retiriĝo restu decido pri unu dosiero, kaj savkopiu la volvan ŝlosilon aparte de la servila agordo, kiun ĝi ebligas. Neniu el la du kutimoj riparas kompromititan profilon, sed ambaŭ decidas, kiom rapide la sekva estos limigita.
Kie la kontrolhoko sidas en la manpremo
La kontrolhoko ruliĝas antaŭ ol la TLS-stako eksponiĝas, kaj ĝia tasko estas inspekti la metadatenojn portatajn en la volvita blob. Ĝi ricevas tiujn metadatenojn plus malgrandan, dokumentitan medion, kaj havas malpli da rimedoj ol aŭtentiga hoko. Supozi, ke ĝi vidas uzantnomojn, seanstan staton aŭ kromprogramajn variablojn, estas la kutima maniero malbone skribi ĉi tiun hokon. Legu la propran manlibran sekcion de la hoko anstataŭ prunti atendojn de alia hoko.
Ĝia elirstato estas la decido: nennula rezulto rifuzas la klienton kaj nula rezulto lasas la manpremon daŭri. La politiko do devas diri, kio okazas kiam metadatenoj mankas, nelegeblas aŭ estas neatenditaj. Skribu unue la rifuzan vojon, poste decidu, kiuj valoroj estas akcepteblaj.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shTiuj du linioj estas la politika surfaco sur la servilo: unu nomas la volvan ŝlosilon, la alia nomas la programon, kiu juĝas ĉiun klienton. Ĉio interesa loĝas en la skripto, kiu meritas versian kontrolon kaj la saman revizion kiel ĉiu alia alirregularo.
Konto, atestilo kaj rega ŝlosilo retiriĝas aparte
Frua akcepto de la rega kanalo ne estas aŭtentigo, ĉar ĝi okazas antaŭ la TLS-identecka kontrolo kaj antaŭ iu ajn konta rajtigo. Malŝalti konton, revoki atestilon kaj rifuzi klientan regan ŝlosilon estas tri agoj kun tri mekanismoj. Elibero, kiu plenumas nur unu el ili, havas breĉon anstataŭ politikon. Konsentigu la tri intence kaj registru, kiu paŝo plenumas kiun aŭtoritaton.
Tempo estas la dua distingo. Ŝanĝita akceptlisto validas por novaj manpremoj, dum jam establitaj seancoj daŭras ĝis io finas ilin. Kalkuli enskribojn en la nova listo kiel pruvon, ke malnovaj seancoj finiĝis, estas kiel forigita kliento restas konektita dum horoj.
Nekonsentigitaj aŭtoritatoj lasas du truojn, kiujn oni facile trovas en praktiko. Konto povas esti malŝaltita dum ĝia rega ŝlosilo ankoraŭ malfermas manpremon, kaj atestilo povas esti revokita dum la metadatenpolitiko ankoraŭ akceptas la saman klienton. Ambaŭ estas la sama eraro en malsamaj lokoj, ĉar administranto traktis unu liston kiel la tutan aŭtoritaton. Metu la tri listojn flank-al-flanke ĉe forigo kaj la eraro fariĝas videbla.
Eldoni kaj retiri profilon
Eldono estas la facila duono: kreu la klientan ŝlosilon ĉe la akceptanta flanko, donu la profilon al ekzakte unu posedanto, tenu la volvan materialon limigita, kaj rulu la saman kontrolprogramon sur ĉiu akceptanta servilo. Malmultekosta eniro estas eco de la tuta grupo, ne de la plej nova gastiganto. Dua servilo kun pli malnova aŭ pli malstrikta skripto silente fariĝas la plej malforta vojo en la eliro.
Retiriĝo bezonas la tri paŝojn en intenca ordo. Rifuzu la klienton en la kontrolhoko por ke novaj manpremoj fiasku, revoku ĝian atestilon se PKI estas uzata, kaj malŝaltu la konton por ke posta rajtigo havu nenion rajtigi. Poste finigu la seancojn, kiujn la malnova akcepto permesis, ĉar ili rimarkos neniun el la tri. Ekzercu la sinsekvon sur kliento, kiun vi povas permesi al vi rompi.
Metadatenoj en profilo estas enigo por tiu politiko, ne pruvo ke alirkontrolo jam ekzistas. La OpenVPN 2.6 projektodokumento priskribas la objektojn kaj la limon, kiun ili desegnas, dum la plenumado restas ĉe la administranto.