OpenVPN tls-crypt-v2: vad klientnyckeln och den inslagna blobben gör

Att klistra in en tls-crypt-v2-profil i ett ärende verkar ofarligt tills man räknar vad filen innehåller. Klientens kontrollkanalnyckel sitter bredvid en krypterad kopia av samma nyckel, och ett tredje objekt, omslagsnyckeln, lämnar aldrig servern som accepterar. Dessa tre svarar på olika frågor om förvar, delning och avveckling. Att skilja dem åt avgör de flesta policydebatter innan de börjar.

Vad profilen faktiskt innehåller

Klienthalvan av tls-crypt-v2 är en nyckel plus en inslagen kopia av den. Klienten använder den vanliga nyckeln för skydd av kontrollkanalen och lämnar den inslagna kopian till servern under installationen, så servern återställer samma nyckel utan att lagra en klartextkopia per klient. Omslagsnyckeln gör den återställningen möjlig och hör bara hemma på den accepterande sidan. Allt nedan följer av var dessa tre objekt bor.

Läs tabellen efter förvar, inte efter namn, och konsekvenserna faller ut av sig själva. Att förlora omslagsnyckeln är den dyra händelsen, eftersom ingenting i en profil kan återskapa den och den ärliga återställningen är att utfärda gruppen på nytt. En läckt profil är billigare men mycket vanligare, eftersom folk klistrar in profiler i ärenden i tron att den inslagna kopian gör filen säker att dela. De två felen kräver olika svar, och det är därför objekten hålls åtskilda.

Varför den inslagna kopian inte är hela historien

En profil bär det användbara klientmaterialet tillsammans med sin inslagna motsvarighet, så att skydda kopian för servern säger ingenting om att skydda filen. Blobben är säker att överföra och osäker att publicera. Metadata inuti den är synlig för alla som tar emot blobben, inklusive alla som senare läser ärendet den klistrades in i.

Behandla en profil som en legitimering, inte som ett konfigurationsexempel. En läckt fil ger innehavaren en fungerande klientidentitet tills servern slutar acceptera den identiteten, och inslagningen gör ingenting åt det fönstret. Utfärda en profil per klient så att återkallande förblir ett beslut om en enda fil, och säkerhetskopiera omslagsnyckeln åtskild från serverkonfigurationen den möjliggör. Ingen av de två vanorna reparerar en komprometterad profil, men båda avgör hur snabbt nästa begränsas.

Var verifieringskroken sitter i handskakningen

Verifieringskroken körs innan TLS-stacken exponeras, och dess uppgift är att granska metadata som bärs i den inslagna blobben. Den tar emot dessa metadata plus en liten, dokumenterad miljö, och har mindre att arbeta med än en autentiseringskrok. Att anta att den ser användarnamn, sessionsstatus eller pluginvariabler är det vanliga sättet denna krok skrivs dåligt. Läs krokens eget avsnitt i handboken i stället för att låna förväntningar från en annan krok.

Dess utgångsstatus är beslutet: ett resultat som inte är noll avvisar klienten och ett nollresultat låter handskakningen fortsätta. Policyn måste därför säga vad som händer när metadata saknas, inte kan tolkas eller är oväntade. Skriv avvisningsvägen först och bestäm sedan vilka värden som är acceptabla.

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

De två raderna är policyns yta på servern: den ena namnger omslagsnyckeln, den andra namnger programmet som bedömer varje klient. Allt intressant bor i skriptet, som förtjänar versionskontroll och samma granskning som varje annan åtkomstregel.

Konto, certifikat och kontrollnyckel avvecklas var för sig

Tidigt accepterande av kontrollkanalen är inte autentisering, eftersom det sker före TLS-identitetskontrollen och före någon kontobehörighet. Att inaktivera ett konto, återkalla ett certifikat och avvisa en klientkontrollnyckel är tre åtgärder med tre mekanismer. En utrullning som bara gör en av dem har en lucka, inte en policy. Stäm av de tre medvetet och registrera vilket steg som utövar vilken behörighet.

Tidpunkten är den andra skillnaden. En ändrad acceptanslista gäller nya handskakningar, medan sessioner som redan upprättats fortsätter tills något avslutar dem. Att räkna poster i den nya listan som bevis på att gamla sessioner är över är hur en borttagen klient blir kvar ansluten i timmar.

Oavstämda behörigheter lämnar två hål som är lätta att hitta i praktiken. Ett konto kan vara inaktiverat medan dess kontrollnyckel fortfarande öppnar en handskakning, och ett certifikat kan vara återkallat medan metadatapolicyn fortfarande tillåter samma klient. Båda är samma misstag på olika ställen, eftersom en operatör behandlade en lista som hela behörigheten. Lägg de tre listorna sida vid sida vid borttagningen och misstaget blir synligt.

Utfärda och dra tillbaka en profil

Utfärdande är den enkla halvan: skapa klientnyckeln på den accepterande sidan, lämna profilen till exakt en ägare, håll omslagsmaterialet begränsat och kör samma verifieringsprogram på varje accepterande server. Billigt tillträde är en egenskap hos hela gruppen, inte hos den nyaste värden. En andra server med ett äldre eller slappare skript blir tyst den svagaste vägen i utrullningen.

Återkallande kräver de tre stegen i en medveten ordning. Avvisa klienten i verifieringskroken så att nya handskakningar misslyckas, återkalla dess certifikat om en PKI används, och inaktivera kontot så att senare behörighet inte har något att bevilja. Avsluta sedan sessionerna som det gamla accepterandet tillät, eftersom de inte kommer märka någon av de tre. Öva sekvensen på en klient du har råd att förstöra.

Metadata i en profil är en indata till den policyn, inte bevis på att åtkomstkontroll redan finns. Designdokumentet för OpenVPN 2.6 beskriver objekten och gränsen de drar, medan verkställandet stannar hos operatören.