Hvorfor openssl rand ikke kan lage nøkkelen tls-crypt vil ha

OpenSSL er allerede installert, verten har entropi, og å generere en nøkkel med det føles som den åpenbare snarveien. Utdataene blir tilfeldige og hemmelige og fullstendig ubrukelige, og feilen kommer som en kontrollkanalfeil i stedet for noe som nevner et nøkkelformat. Den villedningen er den dyre delen, fordi den sender folk til å undersøke chifferne sine. Det VPN leser er en bestemt filstruktur, ikke en vilkårlig blokk med byte, og én variant av funksjonen kan ikke produseres utenfor serveren i det hele tatt.

Hva filen på disken faktisk må være

En statisk nøkkelfil for OpenVPN er tekst. Den begynner med en kommentarlinje som erklærer hva den er, bærer hex-data i rader med fast bredde og utgjør totalt 256 byte nøkkelmateriale. OpenVPN leser den som kontrollkanalens delte hemmelighet, ikke som et sertifikat, ikke som en passfrase og ikke som noe et TLS-bibliotek ville kjenne igjen.

Samme objekttype tjener begge kontrollkanalfunksjonene. Med tls-auth trenger hver peer også en retning, slik at pakkene fra den ene siden ikke kan reflekteres tilbake til den. Med tls-crypt krypterer og autentiserer én delt hemmelighet kontrollkanalen i begge retninger, noe som skjuler håndtrykket og samtidig beskytter det.

Ingenting av dette er hemmelig kunnskap, og formatet er ikke poenget. Poenget er at filen må samsvare nøyaktig med det leseren forventer: header, radebredde, avsluttende linjeskift og total lengde. En fil som er én rad feil lastes som søppel eller feiler helt. Å sammenligne to peers byte for byte er derfor en legitim første test, og den er raskere enn å lese en av de to konfigurasjonsfilene.

Den støttede måten å lage en på

Generer den vanlige statiske nøkkelen med verktøyet som skal bruke den, og referer til den fra begge ender:

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

Stavemåten for valget endret seg over tid: eldre installasjoner fra 2.4-æraen brukte en form med et eget flagg før filnavnet, mens dagens bygg aksepterer den kortere. Uansett er den resulterende filen samme type objekt, så kontrollen er om begge peers har identiske byte.

Den andre generasjonen legger til struktur som ingen ekstern generator kan finne opp. En servernøkkel opprettes én gang, og hver klient mottar en innpakket nøkkel avledet fra 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 mottar er ikke serverens egen nøkkel duplisert. Det er et innpakket objekt som bærer metadata som bare serveren kan pakke ut, og den innpakningen er grunnen til at en fil per enhet kan tilbakekalles uten å berøre noen annen enhet. Hold servernøkkelen på serveren og behandle den som roten til den tilliten per enhet.

Hvor håndlagde byte bryter sammen

Å skrive ut 256 tilfeldige byte som hex under en korrekt header ville i teorien gi en statisk nøkkelfil som lastes. Det er fortsatt en dårlig idé. Hver formateringsdetalj blir en sjanse til å produsere materiale som feiler ved lasting eller, verre, lar to peers sitte med ulike verdier som først avsløres som en autentiseringsfeil.

Ingenting tilsvarende er mulig med v2-varianten. En innpakket klientnøkkel finnes bare som utdata fra servernøkkelprosessen, og serveren beholder materialet som trengs for å pakke den ut. En tilfeldig blob vil bli avvist eller rett og slett ikke klare å dekryptere, og ingen av de to meldingene nevner tilfeldighet.

Versjonskompatibilitet ligger oppå alt dette. Den første generasjonen trenger en utgivelse som støtter den i begge ender, og den andre trenger igjen en nyere utgivelse. En klient bygget før funksjonen fantes kan ikke fullføre et håndtrykk med en server som bare godtar innpakket materiale, og feilen den rapporterer peker på kontrollkanalen i stedet for på versjonen.

Rotere uten å låse alle ute

Å rotere én delt hemmelighet er en koordineringsøvelse, ikke en teknisk. Hver klient trenger erstatningsfilen i hånden før serveren trekker tilbake den forrige, og enhver maskin som fortsatt har den gamle verdien feiler i det øyeblikket. Ikke start den rotasjonen midt i en arbeidsdag.

Med v2-oppsettet er rotasjonen per enhet: utsted en ny innpakket nøkkel for én maskin og pensjoner den gamle bare for den maskinen. Det er hovedargumentet for å bytte når hver klient er på en utgivelse som støtter det.

Filrettigheter hører til i samme samtale. Nøkkelen bør bare kunne leses av kontoen som kjører tjenesten, og den bør ikke ligge i samme depot som profilene den beskytter. OpenVPN 2.6-referansen dokumenterer genereringsformene og avsnittene om nøkkelmateriale, som er en bedre kilde enn en kopiert kommando fra et foruminnlegg.