tls-auth kontra tls-crypt: hvad hver af dem beskytter i OpenVPN

Begge valgmuligheder bruger en delt nøglefil, og begge gør håndtrykstrafik sværere at forfalske, og derfor behandles de som to navne for den samme funktion. Det er de ikke. Den ene signerer kontrolpakker, den anden krypterer dem også, og ingen af dem har noget med chifferen, der beskytter dine data, at gøre.

Den forskel betyder noget, når en profil ikke kan oprette forbindelse, når en sikkerhedsgennemgang spørger, hvad nøglen beskytter, og når nogen antager, at den ekstra fil gør tunnelen krypteret på en eller anden udefineret måde.

Hvad den delte nøgle egentlig beskytter

Nøglen, som disse valgmuligheder bruger, hører til kontrolkanalen: den udveksling, der forhandler parametre, beviser identiteter og udleder datanøglerne. Det er en forudelt hemmelighed, som begge ender skal have, før håndtrykket kan fortsætte. Fordi den ligger før identitetskontrollen, stopper en forkert nøgle samtalen tidligere, end en forkert adgangskode ville. Den rækkefølge forklarer, hvorfor fejltilstanden er så tavs.

tls-auth bruger den hemmelighed til at beregne en HMAC over kontrolpakker. En pakke uden en gyldig signatur kasseres, før den når den dyrere TLS-behandling, og derfor beskrives valgmuligheden ofte som et første filter frem for en erstatning for TLS.

tls-crypt går videre ved at kryptere den beskyttede kontroltrafik ud over at autentificere den. Certifikatindhold, forhandlede chiffernavne og andre håndtryksdetaljer er ikke længere synlige på nettet, og en observatør uden nøglen kan ikke engang se, hvilken TLS-version der forsøges. For en udrulning, der frygter at afsløre sit VPN-fingeraftryk, er den egenskab hovedårsagen til at vælge den. Den er stadig en gruppehemmelighed, ikke en legitimationsoplysning pr. bruger.

Ingen af mekanismerne udsteder identiteter. Den delte nøgle er en gruppehemmelighed, og alle, der har den, kan opfylde det lag af kontrollen.

Hvor de to valgmuligheder adskiller sig

Forskellen, man kan se, er, hvad en observatør ser. Med tls-auth er håndtrykket synligt, men ikke verificerbart uden nøglen. Med tls-crypt er håndtrykket uigennemsigtigt for alle, der ikke har nøglen.

Konfigurationen er også forskellig. tls-auth bruges med en retningsværdi, så den ene side bruger den ene halvdel af nøglematerialet, og den anden side bruger den anden halvdel. tls-crypt bruger en enkelt nøgle i begge retninger, så retningsdirektivet er ikke en del af dens ordning.

De to valgmuligheder udelukker hinanden i moderne udgivelser. En profil skal indeholde en af dem, ikke begge, og serveren og klienten skal blive enige om hvilken, med matchende nøglemateriale. At beholde et gammelt direktiv ved siden af et nyt er et almindeligt migreringsrest. Fjern det inaktive, så den næste læser ved, hvilket lag der faktisk gælder.

En nyere variant, tls-crypt-v2, binder hver klient til sin egen indpakkede nøgle, så tilbagekaldelse af én klient ikke kræver, at gruppenøglen genudstedes. Det er værd at kende, men det er en anden valgmulighed og ikke et synonym for nogen af de to her.

Hvorfor en uoverensstemmelse ser ud, som om der ikke sker noget

Når det delte materiale ikke matcher, kasserer modparten pakkerne uden at fortælle afsenderen hvorfor. Der er ingen godkendelsesfejl at læse, fordi pakken aldrig nåede det lag, der ville producere en.

Klienten prøver igen, serveren siger intet, og symptomet ligner et netværksproblem. Så genstarter folk tjenesten, skriver kontoens adgangskode igen eller fjerner beskyttelsesdirektivet for at «teste» det, hvilket ændrer udrulningen i stedet for at diagnosticere den.

Læs serverloggen for den første klage på pakkeniveau i stedet for den sidste gentagelseslinje. Bekræft, at begge sider har den samme valgmulighed med identisk nøglemateriale, og at nøglefilen ikke blev genskabt på kun den ene side.

At fjerne direktivet er ikke en sikker reparation. Det deaktiverer et beskyttelseslag for hver klient, og en tunnel, der virker bagefter, beviser kun, at laget var uoverensstemmelsen.

Hvad der stadig skal konfigureres separat

Disse valgmuligheder bekræfter ikke, hvem modparten er. Certifikatvalidering, tillidsankeret og det forventede servernavn forbliver separate krav, og ingen af dem bliver valgfri, fordi der findes en delt nøgle.

De vælger heller ikke datachifferen. Det er en separat forhandling, der styres af datakanalens indstillinger på begge parter, og en tunnel beskyttet af tls-crypt kan stadig bruge en chiffer, du ikke havde tænkt dig.

Endelig skal den delte nøgle selv håndteres. Behandl den som en hemmelighed, distribuér den via en godkendt kanal, og udskift den, når nogen, der havde den, forlader. Fordi den deles, er dens eksponering eksponeringen af hver ende, der bruger den.