tls-auth kontra tls-crypt: vad var och en skyddar i OpenVPN

Båda alternativen använder en delad nyckelfil och båda gör handskakningstrafiken svårare att förfalska, därför behandlas de som två namn på samma funktion. Det är de inte. Den ena signerar kontrollpaket, den andra krypterar dem också, och ingen av dem har något med chiffret som skyddar din nyttolast att göra.

Den skillnaden spelar roll när en profil inte kan ansluta, när en säkerhetsgranskning frågar vad nyckeln skyddar, och när någon antar att den extra filen gör tunneln krypterad på något odefinierat sätt.

Vad den delade nyckeln faktiskt skyddar

Nyckeln som dessa alternativ använder hör till kontrollkanalen: det utbyte som förhandlar parametrar, bevisar identiteter och härleder datanycklarna. Det är en i förväg delad hemlighet som båda ändarna måste ha innan handskakningen kan fortsätta. Eftersom den ligger före identitetskontrollerna stoppar en felaktig nyckel samtalet tidigare än ett felaktigt lösenord skulle göra. Den ordningen förklarar varför felmoden är så tyst.

tls-auth använder hemligheten för att beräkna en HMAC över kontrollpaket. Ett paket utan giltig signatur kastas innan det når den dyrare TLS-behandlingen, därför beskrivs alternativet ofta som ett första filter snarare än en ersättning för TLS.

tls-crypt går längre genom att kryptera den skyddade kontrolltrafiken utöver att autentisera den. Certifikatinnehåll, förhandlade chiffernamn och andra handskakningsdetaljer syns inte längre i nätet, och en observatör utan nyckeln kan inte ens se vilken TLS-version som prövas. För en driftsättning som fruktar att avslöja sitt VPN-fingeravtryck är den egenskapen huvudskälet att välja den. Den är fortfarande en grupphemlighet, inte en inloggning per användare.

Ingen av mekanismerna utfärdar identiteter. Den delade nyckeln är en grupphemlighet, och alla som har den kan uppfylla det lagret av kontrollen.

Var de två alternativen skiljer sig

Den observerbara skillnaden är vad en observatör ser. Med tls-auth är handskakningen synlig men inte verifierbar utan nyckeln. Med tls-crypt är handskakningen ogenomtränglig för alla som inte har nyckeln.

Konfigurationen skiljer sig också. tls-auth används med ett riktningsvärde, så den ena sidan använder den ena hälften av nyckelmaterialet och den andra sidan den andra hälften. tls-crypt använder en enda nyckel i båda riktningarna, så riktningsdirektivet ingår inte i dess upplägg.

I moderna utgåvor utesluter de två alternativen varandra. En profil bör innehålla ett av dem, inte båda, och servern och klienten måste enas om vilket, med matchande nyckelmaterial. Att behålla ett gammalt direktiv bredvid ett nytt är en vanlig migreringsrest. Ta bort det inaktiva så att nästa läsare vet vilket lager som faktiskt gäller.

En nyare variant, tls-crypt-v2, binder varje klient till sin egen inpackade nyckel, så att återkallande av en klient inte kräver att gruppnyckeln utfärdas på nytt. Det är värt att känna till, men det är ett annat alternativ och inte en synonym till något av de två här.

Varför en felaktig matchning ser ut som om ingenting händer

När det delade materialet inte stämmer kastar motparten paketen utan att berätta för avsändaren varför. Det finns inget autentiseringsfel att läsa, eftersom paketet aldrig nådde lagret som skulle ha producerat ett.

Klienten försöker igen, servern säger ingenting, och symtomet ser ut som ett nätverksproblem. Då startar folk om tjänsten, skriver in kontolösenordet igen eller tar bort skyddsdirektivet för att «testa» det, vilket ändrar driftsättningen i stället för att diagnosticera den.

Läs i serverloggen det första klagomålet på paketnivå i stället för den sista återförsöksraden. Bekräfta att båda sidor har samma alternativ med identiskt nyckelmaterial och att nyckelfilen inte återskapades på bara ena sidan.

Att ta bort direktivet är inte en säker reparation. Det stänger av ett skyddslager för varje klient, och en tunnel som fungerar efteråt bevisar bara att lagret var den felaktiga matchningen.

Vad som fortfarande måste konfigureras separat

Dessa alternativ verifierar inte vem motparten är. Certifikatvalidering, förtroendeankaret och det förväntade servernamnet är fortfarande separata krav, och inget av dem blir valfritt för att det finns en delad nyckel.

De väljer inte heller datachiffret. Det är en separat förhandling som styrs av datakanalens inställningar på båda sidor, och en tunnel som skyddas av tls-crypt kan fortfarande använda ett chiffer du inte avsåg.

Slutligen behöver den delade nyckeln själv hantering. Behandla den som en hemlighet, distribuera den via en godkänd kanal och byt ut den när någon som hade den slutar. Eftersom den delas är dess exponering exponeringen av varje ände som använder den.