Hvorfor openssl rand ikke kan lave den nøgle, tls-crypt kræver

OpenSSL er allerede installeret, værten har entropi, og det føles som den oplagte genvej at generere en nøgle med det. Outputtet bliver tilfældigt og hemmeligt og fuldstændig ubrugeligt, og fejlen viser sig som en kontrolkanalfejl i stedet for noget, der nævner et nøgleformat. Den vildledning er den dyre del, fordi den sender folk til at undersøge deres ciphers. Det, VPN'et læser, er en bestemt filstruktur, ikke en vilkårlig blok bytes, og én variant af funktionen kan slet ikke fremstilles uden for serveren.

Hvad filen på disken faktisk skal være

En statisk nøglefil til OpenVPN er tekst. Den begynder med en kommentarlinje, der angiver, hvad den er, indeholder hex-data i rækker med fast bredde og udgør i alt 256 byte nøglemateriale. OpenVPN læser den som kontrolkanalens fælles hemmelighed, ikke som et certifikat, ikke som en adgangsfrase og ikke som noget, en TLS-bibliotek ville genkende.

Den samme objekttype tjener begge kontrolkanalens funktioner. Med tls-auth har hver peer også brug for en retning, så den ene sides pakker ikke kan sendes tilbage til den. Med tls-crypt krypterer og autentificerer én fælles hemmelighed kontrolkanalen i begge retninger, hvilket skjuler handshaket og samtidig beskytter det.

Intet af det er hemmelig viden, og formatet er ikke pointen. Pointen er, at filen skal matche præcis det, læseren forventer: header, rækkebredde, afsluttende linjeskift og samlet længde. En fil, der er en række ved siden af, indlæses som skrald eller fejler helt. En byte-for-byte-sammenligning af to peers er derfor en legitim første test, og den er hurtigere end at læse en af de to konfigurationsfiler.

Den understøttede måde at lave en på

Generer den almindelige statiske nøgle med det værktøj, der skal bruge den, og referer til den fra begge ender:

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

Stavemåden for indstillingen ændrede sig over tid: ældre installationer fra 2.4-æraen brugte en form med et separat flag før filnavnet, mens aktuelle builds accepterer den kortere. Uanset hvad er den resulterende fil den samme slags objekt, så tjekket er, om begge peers har identiske bytes.

Anden generation tilføjer struktur, som ingen ekstern generator kan opfinde. En servernøgle oprettes én gang, og hver klient modtager en indpakket nøgle, der er afledt af 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 modtager, er ikke serverens egen nøgle duplikeret. Det er et indpakket objekt med metadata, som kun serveren kan pakke ud, og den indpakning er grunden til, at en fil per enhed kan tilbagekaldes uden at røre nogen anden enhed. Behold servernøglen på serveren, og behandl den som roden til den tillid per enhed.

Hvor håndlavede bytes bryder sammen

At printe 256 tilfældige bytes som hex under en korrekt header ville i teorien give en statisk nøglefil, der indlæses. Det er stadig en dårlig idé. Hver formateringsdetalje bliver en chance for at producere materiale, der fejler ved indlæsning eller, værre, efterlader to peers med forskellige værdier, som først viser sig som en autentificeringsfejl.

Intet tilsvarende er muligt med v2-varianten. En indpakket klientnøgle findes kun som output fra serverens nøgleproces, og serveren beholder det materiale, der er nødvendigt for at pakke den ud. En tilfældig blob vil blive afvist eller simpelthen fejle med at dekryptere, og ingen af meddelelserne nævner tilfældighed.

Versionskompatibilitet ligger oven på alt dette. Den første generation kræver en udgivelse, der understøtter den i begge ender, og den anden kræver igen en nyere udgivelse. En klient, der er bygget før funktionen fandtes, kan ikke gennemføre et handshake med en server, der kun accepterer indpakket materiale, og den fejl, den rapporterer, peger på kontrolkanalen i stedet for på versionen.

Rotering uden at låse alle ude

At rotere én fælles hemmelighed er en koordinationsøvelse snarere end en teknisk. Hver klient skal have erstatningsfilen ved hånden, før serveren trækker den forrige tilbage, og enhver maskine, der stadig har den gamle værdi, fejler i det øjeblik. Start ikke den rotering midt på en arbejdsdag.

Med v2-ordningen er roteringen per enhed: udsted en ny indpakket nøgle til én maskine, og udfas den gamle for den maskine alene. Det er hovedargumentet for at skifte, når hver klient er på en udgivelse, der understøtter det.

Filrettigheder hører til i samme samtale. Nøglen bør kun kunne læses af den konto, der kører tjenesten, og den bør ikke ligge i samme repository som de profiler, den beskytter. OpenVPN 2.6-reference dokumenterer genereringsformerne og afsnittene om nøglemateriale, hvilket er en bedre kilde end en kopieret kommando fra et forumindlæg.