Kvifor openssl rand ikkje kan lage nøkkelen tls-crypt vil ha

OpenSSL er allereie installert, verten har entropi, og å lage ein nøkkel med det kjennest som den openberre snøggvegen. Utdataa blir tilfeldige og hemmelege og heilt ubrukelege, og feilen kjem som ein kontrollkanalfeil i staden for noko som nemner eit nøkkelformat. Den villleiinga er den dyre delen, fordi ho sender folk til å undersøkje siffera sine. Det VPN les er ein bestemd filstruktur, ikkje ein vilkårleg blokk med byte, og éin variant av funksjonen kan ikkje produserast utanfor serveren i det heile.

Kva fila på disken faktisk må vere

Ei statisk nøkkelfil for OpenVPN er tekst. Ho byrjar med ei kommentarlinje som erklærer kva ho er, ber hex-data i rader med fast breidd og utgjer totalt 256 byte nøkkelmateriale. OpenVPN les ho som kontrollkanalen sin delte hemmelegheit, ikkje som eit sertifikat, ikkje som ei passfrase og ikkje som noko eit TLS-bibliotek ville kjenne att.

Same objekttype tener begge kontrollkanalfunksjonane. Med tls-auth treng kvar peer òg ei retning, slik at pakkane frå den eine sida ikkje kan reflekterast tilbake til han. Med tls-crypt krypterer og autentiserer éi delt hemmelegheit kontrollkanalen i begge retningar, noko som skjuler handtrykket og samstundes vernar det.

Ingenting av dette er hemmeleg kunnskap, og formatet er ikkje poenget. Poenget er at fila må samsvare nøyaktig med det lesaren ventar: hovud, radebreidd, avsluttande linjeskift og total lengd. Ei fil som er éi rad feil blir lasta som søppel eller feilar heilt. Å samanlikne to peerar byte for byte er difor ein legitim første test, og han er raskare enn å lese ein av dei to konfigurasjonsfilene.

Den støtta måten å lage éi på

Generer den vanlege statiske nøkkelen med verktøyet som skal bruke han, og vis så til han frå begge endar:

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

Stavemåten for valet endra seg over tid: eldre installasjonar frå 2.4-æraen brukte ei form med eit eige flagg før filnamnet, medan dagens bygg godtek den kortare. Uansett er den resulterande fila same type objekt, så kontrollen er om begge peerane har identiske byte.

Den andre generasjonen legg til struktur som ingen ekstern generator kan finne opp. Ein servernøkkel blir oppretta éin gong, og kvar klient får ein innpakka nøkkel avleidd frå han:

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 er ikkje serveren sin eigen nøkkel duplisert. Det er eit innpakka objekt som ber metadata som berre serveren kan pakke ut, og den innpakkinga er grunnen til at ei fil per eining kan kallast tilbake utan å røre noka anna eining. Hald servernøkkelen på serveren og handsam han som rota til den tillita per eining.

Kvar handlaga byte bryt saman

Å skrive ut 256 tilfeldige byte som hex under eit korrekt hovud ville i teorien gje ei statisk nøkkelfil som blir lasta. Det er framleis ein dårleg idé. Kvar formateringsdetalj blir ein sjanse til å produsere materiale som feilar ved lasting eller, verre, lèt to peerar sitje med ulike verdiar som først avdekkjer seg som ein autentiseringsfeil.

Ingenting tilsvarande er mogleg med v2-varianten. Ein innpakka klientnøkkel finst berre som utdata frå servernøkkelprosessen, og serveren held på materialet som trengst for å pakke han ut. Ein tilfeldig blob blir avvist eller klarar rett og slett ikkje å dekryptere, og ingen av dei to meldingane nemner tilfeldigheit.

Versjonskompatibilitet ligg oppå alt dette. Den første generasjonen treng ein utgiving som støttar han i begge endar, og den andre treng igjen ein nyare utgiving. Ein klient bygd før funksjonen fanst kan ikkje fullføre eit handtrykk med ein server som berre godtek innpakka materiale, og feilen han rapporterer peikar på kontrollkanalen i staden for på versjonen.

Rotere utan å låse alle ute

Å rotere éi delt hemmelegheit er ei koordineringsøving, ikkje ei teknisk. Kvar klient treng erstatningsfila i handa før serveren trekkjer tilbake den førre, og kvar maskin som framleis har den gamle verdien feilar i det augeblikket. Ikkje start den rotasjonen midt i ein arbeidsdag.

Med v2-oppsettet er rotasjonen per eining: gi ut ein ny innpakka nøkkel for éi maskin og pensjoner den gamle berre for den maskina. Det er hovudargumentet for å bytte når kvar klient er på ei utgiving som støttar det.

Filrettar høyrer til i same samtale. Nøkkelen bør berre kunne lesast av kontoen som køyrer tenesta, og han bør ikkje liggje i same depot som profilane han vernar. OpenVPN 2.6-referansen dokumenterer genereringsformene og avsnitta om nøkkelmateriale, som er ei betre kjelde enn ein kopiert kommando frå eit foruminnlegg.