OpenVPN tls-crypt-v2: kva klientnøkkelen og den innpakka bloben gjer

Å lima ein tls-crypt-v2-profil inn i ein sak verkar ufarleg til du tel kva fila inneheld. Kontrollkanalnøkkelen til klienten sit ved sida av ein kryptert kopi av same nøkkelen, og eit tredje objekt, innpakkingsnøkkelen, forlèt aldri serveren som godtek. Desse tre svarar på ulike spørsmål om oppbevaring, deling og avvikling. Å skilja dei avgjer dei fleste policydebattene før dei byrjar.

Kva profilen faktisk inneheld

Klienthalvdelen av tls-crypt-v2 er ein nøkkel pluss ein innpakka kopi av han. Klienten brukar den vanlege nøkkelen til vern av kontrollkanalen og overleverer den innpakka kopien til serveren under oppsettet, slik at serveren gjenopprettar same nøkkel utan å lagra ein klartekstkopi per klient. Innpakkingsnøkkelen gjer den gjenopprettinga mogleg og høyrer berre heime på godtakande side. Alt nedanfor følgjer av kvar desse tre objekta bur.

Les tabellen etter oppbevaring, ikkje etter namn, og konsekvensane fell ut av seg sjølve. Å missa innpakkingsnøkkelen er den dyre hendinga, fordi ingenting i ein profil kan byggja han opp att, og den ærlege gjenopprettinga er å gje gruppa ut på nytt. Ein leken profil er billegare, men langt vanlegare, fordi folk limer profilar inn i saker i trua på at den innpakka kopien gjer fila trygg å dela. Dei to feila krev ulike svar, og det er grunnen til at objekta blir haldne åtskilde.

Kvifor den innpakka kopien ikkje er heile historia

Ein profil ber det brukbare klientmaterialet saman med sin innpakka motpart, så å verna kopien for serveren seier ingenting om å verna fila. Bloben er trygg å senda og utrygg å publisera. Metadataa i han er synlege for alle som mottek bloben, inkludert alle som seinare les saka han vart lima inn i.

Handsam ein profil som ein legitimasjon, ikkje som eit konfigurasjonseksempel. Ei leken fil gjev innehavaren ein fungerande klientidentitet til serveren sluttar å godta den identiteten, og innpakkinga gjer ingenting med det vindauget. Gje ut éin profil per klient slik at tilbaketrekking blir ei avgjerd om éi fil, og ta tryggingskopi av innpakkingsnøkkelen åtskild frå serverkonfigurasjonen han gjer mogleg. Ingen av dei to vanane reparerer ein kompromittert profil, men begge avgjer kor raskt den neste blir avgrensa.

Kvar verifiseringskroken sit i handtrykket

Verifiseringskroken køyrer før TLS-stakken blir eksponert, og jobben er å inspisera metadataa som blir borne i den innpakka bloben. Han mottek desse metadataa pluss eit lite, dokumentert miljø, og han har mindre å arbeida med enn ein autentiseringskrok. Å anta at han ser brukarnamn, sesjonstilstand eller pluginvariablar er den vanlege måten denne kroken blir skriven dårleg på. Les kroken sin eigen handbokdel i staden for å låna forventningar frå ein annan krok.

Utgangsstatusen er avgjerda: eit resultat som ikkje er null avviser klienten, og eit nullresultat lèt handtrykket halda fram. Policyen må difor seia kva som skjer når metadata manglar, ikkje kan tolkast eller er uventa. Skriv avvisingsvegen først, og avgjer deretter kva verdiar som er akseptable.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Dei to linjene er policymflata på serveren: den eine namngjev innpakkingsnøkkelen, den andre namngjev programmet som vurderer kvar klient. Alt interessant bur i skriptet, som fortener versjonskontroll og same gjennomgang som kvar annan tilgangsregel.

Konto, sertifikat og kontrollnøkkel går ut kvar for seg

Tidleg godtaking av kontrollkanalen er ikkje autentisering, fordi ho skjer før TLS-identitetssjekken og før noka kontogodkjenning. Å deaktivera ein konto, tilbakekalla eit sertifikat og avvisa ein klientkontrollnøkkel er tre handlingar med tre mekanismar. Ei utrulling som berre gjer éin av dei har eit gap, ikkje ein policy. Avstem dei tre med vilje, og registrer kva trinn som utøver kva myndigheit.

Tidspunktet er den andre skilnaden. Ei endra godtakingsliste gjeld nye handtrykk, medan sesjonar som alt er etablerte held fram til noko avsluttar dei. Å telja oppføringar i den nye lista som prov på at gamle sesjonar er over, er korleis ein fjerna klient blir verande tilkopla i timar.

Uavstemde myndigheiter lèt etter seg to hol som er lette å finna i praksis. Ein konto kan vera deaktivert medan kontrollnøkkelen hans framleis opnar eit handtrykk, og eit sertifikat kan vera tilbakekalla medan metadatapolicyen framleis godtek same klient. Begge er same feil på ulike stader, fordi ein operatør handsama éi liste som heile myndigheita. Legg dei tre listene side ved side ved fjerning, og feilen blir synleg.

Gje ut og trekkja tilbake ein profil

Utgiving er den enkle halvdelen: lag klientnøkkelen på godtakande side, overlever profilen til nøyaktig éin eigar, hald innpakkingsmaterialet avgrensa, og køyr same verifiseringsprogram på kvar godtakande server. Billeg tilgang er ein eigenskap ved heile gruppa, ikkje ved den nyaste verten. Ein andre server med eit eldre eller slakkare skript blir stille den svakaste vegen i utrullinga.

Tilbaketrekking krev dei tre trinna i ei medviten rekkjefølgje. Avvis klienten i verifiseringskroken slik at nye handtrykk feilar, tilbakekall sertifikatet om ein PKI blir brukt, og deaktiver kontoen slik at seinare godkjenning ikkje har noko å godkjenna. Avslutt deretter sesjonane som den gamle godtakinga tillét, sidan dei ikkje vil merka nokon av dei tre. Øv rekkjefølgja på ein klient du har råd til å øydeleggja.

Metadata i ein profil er eit innspel til den policyen, ikkje prov på at tilgangskontroll alt finst. Designdokumentet for OpenVPN 2.6 skildrar objekta og grensa dei dreg, medan handhevinga blir hos operatøren.