OpenVPN tls-crypt-v2: hvad klientnøglen og den indpakkede blob gør
En tls-crypt-v2-profil indeholder en klientkontrolnøgle og en indpakket kopi, som kun serveren kan åbne. Hold hvert objekt og hvert tilbagetrækningstrin adskilt.
Det ser uskadeligt ud at indsætte en tls-crypt-v2-profil i en sag, indtil man tæller, hvad filen indeholder. Klientens kontrolkanalnøgle står ved siden af en krypteret kopi af samme nøgle, og et tredje objekt, indpakningsnøglen, forlader aldrig den accepterende server. De tre besvarer forskellige spørgsmål om opbevaring, deling og tilbagetrækning. At skille dem ad afgør de fleste politikdiskussioner, før de begynder.
Hvad profilen faktisk indeholder
Klienthalvdelen af tls-crypt-v2 er en nøgle plus en indpakket kopi af den. Klienten bruger den klare nøgle til beskyttelse af kontrolkanalen og giver den indpakkede kopi til serveren under opsætningen, så serveren gendanner samme nøgle uden at gemme en klartekstkopi pr. klient. Indpakningsnøglen gør den gendannelse mulig og hører kun til på den accepterende side. Alt nedenfor følger af, hvor de tre objekter ligger.
| 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 |
Læs tabellen efter opbevaring i stedet for efter navn, og konsekvenserne falder ud. At miste indpakningsnøglen er den dyre begivenhed, fordi intet i en profil kan genskabe den, og den ærlige gendannelse er at udstede gruppen igen. En lækket profil er billigere men langt mere almindelig, fordi profiler bliver indsat i sager af folk, der tror, at den indpakkede kopi gør filen sikker at dele. De to fejl kræver forskellige svar, og det er grunden til at holde objekterne adskilt.
Hvorfor den indpakkede kopi ikke er hele historien
En profil bærer det brugbare klientmateriale sammen med sin indpakkede modpart, så beskyttelse af kopien til serveren siger intet om beskyttelse af filen. Bloben er sikker at sende og usikker at offentliggøre. Metadata indeni er synlig for enhver, der modtager bloben, også for enhver, der senere læser den sag, den blev indsat i.
Behandl en profil som en adgangslegitimation i stedet for en konfigurationsprøve. En lækket fil giver sin indehaver en fungerende klientidentitet, indtil serveren holder op med at acceptere den identitet, og indpakningen gør intet ved det vindue. Udsted én profil pr. klient, så tilbagetrækning forbliver en beslutning om én fil, og tag backup af indpakningsnøglen adskilt fra den serverkonfiguration, den muliggør. Ingen af de vaner reparerer en kompromitteret profil, men begge afgør, hvor hurtigt den næste bliver inddæmmet.
Hvor verifikationskrogen sidder i håndtrykket
Verifikationskrogen kører, før TLS-stakken eksponeres, og dens opgave er at undersøge de metadata, der bæres i den indpakkede blob. Den modtager disse metadata plus et lille, dokumenteret miljø og har mindre at arbejde med end en autentificeringskrog. At antage, at den kan se brugernavne, sessionstilstand eller plugin-variabler, er den sædvanlige måde, denne krog bliver skrevet dårligt på. Læs krogens egen manualsektion i stedet for at låne forventninger fra en anden krog.
Dens exitstatus er beslutningen: et resultat forskelligt fra nul afviser klienten, og et nulresultat lader håndtrykket fortsætte. Politikken skal derfor sige, hvad der sker, når metadata mangler, ikke kan parses eller er uventede. Skriv afvisningsvejen først, og beslut derefter, hvilke værdier der er acceptable.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shDe to linjer er politikkens overflade på serveren: den ene navngiver indpakningsnøglen, den anden navngiver det program, der dømmer hver klient. Alt interessant bor i scriptet, som fortjener versionskontrol og samme gennemgang som enhver anden adgangsregel.
Konto, certifikat og kontrolnøgle trækkes tilbage hver for sig
Tidlig accept af kontrolkanalen er ikke autentificering, fordi det sker før TLS-identitetskontrollen og før enhver kontogodkendelse. At deaktivere en konto, tilbagekalde et certifikat og afvise en klientkontrolnøgle er tre handlinger med tre mekanismer. En udrulning, der kun udfører én af dem, har et hul i stedet for en politik. Afstem de tre bevidst, og noter, hvilket trin der udøver hvilken myndighed.
Timing er den anden forskel. En ændret acceptliste gælder for nye håndtryk, mens allerede etablerede sessioner fortsætter, indtil noget afslutter dem. At tælle poster i den nye liste som bevis for, at gamle sessioner er slut, er hvordan en fjernet klient bliver ved med at være forbundet i timer.
Uafstemte myndigheder efterlader to huller, der er lette at finde i praksis. En konto kan deaktiveres, mens dens kontrolnøgle stadig åbner et håndtryk, og et certifikat kan tilbagekaldes, mens metadata-politikken stadig tillader den samme klient. Begge er den samme fejl på forskellige steder, fordi en operatør behandlede én liste som hele myndigheden. Læg de tre lister ved siden af hinanden ved fjernelse, og fejlen bliver synlig.
At udstede og trække en profil tilbage
Udstedelse er den lette halvdel: opret klientnøglen på den accepterende side, giv profilen til præcis én ejer, hold indpakningsmaterialet begrænset, og kør det samme verifikationsprogram på hver accepterende server. Billig adgang er en egenskab ved hele gruppen, ikke ved den nyeste vært. En anden server med et ældre eller løsere script bliver lydløst den svageste vej i udrulningen.
Tilbagetrækning kræver de tre trin i en bevidst rækkefølge. Afvis klienten i verifikationskrogen, så nye håndtryk fejler, tilbagekald dens certifikat, hvis en PKI er i brug, og deaktiver kontoen, så senere godkendelse ikke har noget at godkende. Afslut derefter de sessioner, den gamle accept tillod, da de ikke vil bemærke nogen af de tre. Øv rækkefølgen på en klient, du har råd til at ødelægge.
Metadata i en profil er et input til den politik, ikke bevis for at adgangskontrol allerede findes. OpenVPN 2.6-designdokumentet beskriver objekterne og den grænse, de tegner, mens håndhævelsen forbliver hos operatøren.