Varför openssl rand inte kan skapa nyckeln som tls-crypt vill ha

OpenSSL är redan installerat, värden har entropi, och att generera en nyckel med det känns som den självklara genvägen. Utdata blir slumpmässig och hemlig och helt oanvändbar, och felet kommer som ett styrkanalsfel i stället för något som nämner ett nyckelformat. Den vilseledningen är den dyra delen, eftersom den skickar folk att undersöka sina chiffer. Det VPN läser är en bestämd filstruktur, inte ett godtyckligt block med byte, och en variant av funktionen kan inte alls tillverkas utanför servern.

Vad filen på disken faktiskt måste vara

En statisk nyckelfil för OpenVPN är text. Den börjar med en kommentarsrad som deklarerar vad den är, bär hexdata i rader med fast bredd och utgör totalt 256 byte nyckelmaterial. OpenVPN läser den som styrkanalens delade hemlighet, inte som ett certifikat, inte som en lösenfras och inte som något ett TLS-bibliotek skulle känna igen.

Samma objekttyp tjänar båda styrkanalens funktioner. Med tls-auth behöver varje peer också en riktning så att den ena sidans paket inte kan reflekteras tillbaka till den. Med tls-crypt krypterar och autentiserar en enda delad hemlighet styrkanalen i båda riktningarna, vilket döljer handskakningen och samtidigt skyddar den.

Inget av detta är hemlig kunskap, och formatet är inte poängen. Poängen är att filen måste stämma exakt med vad läsaren förväntar sig: huvud, radbredd, avslutande ny rad och total längd. En fil som är en rad fel läses in som skräp eller misslyckas helt. Att jämföra två peers byte för byte är därför ett legitimt första test, och det är snabbare än att läsa någon av de två konfigurationsfilerna.

Det stödda sättet att skapa en

Generera den vanliga statiska nyckeln med verktyget som ska använda den och referera sedan till den från båda ändar:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

Stavningen av alternativet ändrades med tiden: äldre installationer från 2.4-eran använde en form med en separat flagga före filnamnet, medan nuvarande byggen accepterar den kortare. Hur som helst är den resulterande filen samma typ av objekt, så kontrollen är om båda peerarna har identiska byte.

Den andra generationen lägger till en struktur som ingen extern generator kan hitta på. En servernyckel skapas en gång, och varje klient får en inpackad nyckel som härleds från den:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Det klienten får är inte serverns egen nyckel duplicerad. Det är ett inpackat objekt som bär metadata som bara servern kan packa upp, och den inpackningen är anledningen till att en fil per enhet kan återkallas utan att röra någon annan enhet. Håll servernyckeln på servern och behandla den som roten till det förtroendet per enhet.

Där handgjorda byte brakar samman

Att skriva ut 256 slumpmässiga byte som hex under ett korrekt huvud skulle i teorin ge en statisk nyckelfil som läses in. Det är fortfarande en dålig idé. Varje formateringsdetalj blir en chans att producera material som misslyckas vid inläsning eller, värre, lämnar två peers med olika värden som först avslöjas som ett autentiseringsfel.

Inget motsvarande är möjligt med v2-varianten. En inpackad klientnyckel finns bara som utdata från servernyckelprocessen, och servern behåller materialet som behövs för att packa upp den. En slumpmässig blob avvisas eller lyckas helt enkelt inte dekryptera, och ingen av de två meddelandena nämner slumpmässighet.

Versionskompatibilitet ligger ovanpå allt detta. Den första generationen kräver en utgåva som stöder den i båda ändar, och den andra kräver återigen en nyare utgåva. En klient byggd innan funktionen fanns kan inte slutföra en handskakning med en server som bara accepterar inpackat material, och felet den rapporterar pekar på styrkanalen i stället för på versionen.

Rotera utan att låsa ute alla

Att rotera en enda delad hemlighet är en samordningsövning, inte en teknisk. Varje klient behöver ersättningsfilen i handen innan servern drar tillbaka den förra, och varje maskin som fortfarande har det gamla värdet misslyckas i samma ögonblick. Börja inte den rotationen mitt på en arbetsdag.

Med v2-uppställningen är rotationen per enhet: utfärda en ny inpackad nyckel för en maskin och dra tillbaka den gamla bara för den maskinen. Det är huvudargumentet för att byta när varje klient är på en utgåva som stöder det.

Filrättigheter hör till samma samtal. Nyckeln bör bara kunna läsas av kontot som kör tjänsten, och den bör inte ligga i samma arkiv som profilerna den skyddar. OpenVPN 2.6-referensen dokumenterar genereringsformerna och avsnitten om nyckelmaterial, vilket är en bättre källa än ett kopierat kommando från ett foruminlägg.