OpenVPN tls-crypt-v2: hva klientnøkkelen og den innpakkede bloben gjør
En tls-crypt-v2-profil inneholder en klientkontrollnøkkel og en innpakket kopi som bare serveren kan åpne. Hold hvert objekt og hvert avviklingstrinn atskilt.
Å lime en tls-crypt-v2-profil inn i en sak virker ufarlig til du teller hva filen inneholder. Klientens kontrollkanalnøkkel sitter ved siden av en kryptert kopi av samme nøkkel, og et tredje objekt, innpakningsnøkkelen, forlater aldri serveren som godtar. Disse tre svarer på ulike spørsmål om oppbevaring, deling og avvikling. Å skille dem avgjør de fleste policydebatter før de begynner.
Hva profilen faktisk inneholder
Klienthalvdelen av tls-crypt-v2 er en nøkkel pluss en innpakket kopi av den. Klienten bruker den vanlige nøkkelen til beskyttelse av kontrollkanalen og overleverer den innpakkede kopien til serveren under oppsettet, slik at serveren gjenoppretter samme nøkkel uten å lagre en klartekstkopi per klient. Innpakningsnøkkelen gjør den gjenopprettingen mulig og hører bare hjemme på godtakende side. Alt nedenfor følger av hvor disse tre objektene bor.
| 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 |
Les tabellen etter oppbevaring, ikke etter navn, og konsekvensene faller ut av seg selv. Å miste innpakningsnøkkelen er den dyre hendelsen, fordi ingenting i en profil kan gjenoppbygge den, og den ærlige gjenopprettingen er å utstede gruppen på nytt. En lekket profil er billigere, men langt vanligere, fordi folk limer profiler inn i saker i troen på at den innpakkede kopien gjør filen trygg å dele. De to feilene krever ulike svar, og det er grunnen til at objektene holdes atskilt.
Hvorfor den innpakkede kopien ikke er hele historien
En profil bærer det brukbare klientmaterialet sammen med sin innpakkede motpart, så å beskytte kopien for serveren sier ingenting om å beskytte filen. Bloben er trygg å sende og utrygg å publisere. Metadataene i den er synlige for alle som mottar bloben, inkludert alle som senere leser saken den ble limt inn i.
Behandle en profil som en legitimasjon, ikke som et konfigurasjonseksempel. En lekket fil gir innehaveren en fungerende klientidentitet til serveren slutter å godta den identiteten, og innpakningen gjør ingenting med det vinduet. Utsted én profil per klient slik at tilbaketrekking forblir en enkeltfilavgjørelse, og ta sikkerhetskopi av innpakningsnøkkelen atskilt fra serverkonfigurasjonen den muliggjør. Ingen av de to vanene reparerer en kompromittert profil, men begge avgjør hvor raskt den neste blir begrenset.
Hvor verifiseringskroken sitter i håndtrykket
Verifiseringskroken kjører før TLS-stakken eksponeres, og jobben er å inspisere metadataene som bæres i den innpakkede bloben. Den mottar disse metadataene pluss et lite, dokumentert miljø, og den har mindre å arbeide med enn en autentiseringskrok. Å anta at den ser brukernavn, sesjonstilstand eller pluginvariabler er den vanlige måten denne kroken skrives dårlig på. Les krokens egen håndbokdel i stedet for å låne forventninger fra en annen krok.
Utgangsstatusen er avgjørelsen: et resultat som ikke er null avviser klienten, og et nullresultat lar håndtrykket fortsette. Policyen må derfor si hva som skjer når metadata mangler, ikke kan tolkes eller er uventet. Skriv avvisningsveien først, og bestem deretter hvilke verdier som er akseptable.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shDe to linjene er policymflaten på serveren: den ene navngir innpakningsnøkkelen, den andre navngir programmet som vurderer hver klient. Alt interessant bor i skriptet, som fortjener versjonskontroll og samme gjennomgang som enhver annen tilgangsregel.
Konto, sertifikat og kontrollnøkkel avvikles hver for seg
Tidlig godtakelse av kontrollkanalen er ikke autentisering, fordi den skjer før TLS-identitetssjekken og før noen kontogodkjenning. Å deaktivere en konto, tilbakekalle et sertifikat og avvise en klientkontrollnøkkel er tre handlinger med tre mekanismer. En utrulling som bare gjør én av dem har et gap, ikke en policy. Avstem de tre med vilje, og registrer hvilket trinn som utøver hvilken myndighet.
Tidspunktet er den andre forskjellen. En endret godtakelsesliste gjelder nye håndtrykk, mens sesjoner som allerede er etablert fortsetter til noe avslutter dem. Å telle oppføringer i den nye listen som bevis på at gamle sesjoner er over, er hvordan en fjernet klient blir værende tilkoblet i timer.
Uavstemte myndigheter etterlater to hull som er lette å finne i praksis. En konto kan være deaktivert mens kontrollnøkkelen fortsatt åpner et håndtrykk, og et sertifikat kan være tilbakekalt mens metadatapolicyen fortsatt godtar samme klient. Begge er samme feil på ulike steder, fordi en operatør behandlet én liste som hele myndigheten. Legg de tre listene side ved side ved fjerning, og feilen blir synlig.
Utstede og trekke tilbake en profil
Utstedelse er den enkle halvdelen: lag klientnøkkelen på godtakende side, overlever profilen til nøyaktig én eier, hold innpakningsmaterialet begrenset, og kjør samme verifiseringsprogram på hver godtakende server. Billig adgang er en egenskap ved hele gruppen, ikke ved den nyeste verten. En andre server med et eldre eller slakkere skript blir stille den svakeste veien i utrullingen.
Tilbaketrekking krever de tre trinnene i en bevisst rekkefølge. Avvis klienten i verifiseringskroken slik at nye håndtrykk feiler, tilbakekall sertifikatet hvis en PKI brukes, og deaktiver kontoen slik at senere godkjenning ikke har noe å godkjenne. Avslutt deretter sesjonene som den gamle godtakelsen tillot, siden de ikke vil merke noen av de tre. Øv rekkefølgen på en klient du har råd til å ødelegge.
Metadata i en profil er et innspill til den policyen, ikke bevis på at tilgangskontroll allerede finnes. Designdokumentet for OpenVPN 2.6 beskriver objektene og grensen de trekker, mens håndhevingen blir hos operatøren.