Waarom openssl rand nie die sleutel kan maak wat tls-crypt wil hê nie

OpenSSL is reeds geïnstalleer, die gasheer het entropie, en om 'n sleutel daarmee te skep voel soos die ooglopende kortpad. Die uitset sal ewekansig en geheim en heeltemal onbruikbaar wees, en die fout kom as 'n beheerkanaalfout eerder as iets wat 'n sleutelformaat noem. Daardie misleiding is die duur deel, want dit stuur mense om hul syfers te ondersoek. Wat die VPN lees, is 'n spesifieke lêerstruktuur, nie 'n willekeurige blok grepe nie, en een variant van die funksie kan glad nie buite die bediener vervaardig word nie.

Wat die lêer op skyf werklik moet wees

'n Statiese sleutellêer van OpenVPN is teks. Dit begin met 'n kommentaarlyn wat verklaar wat dit is, dra hex-data in rye van vaste wydte, en beloop 256 grepe se sleutelmateriaal. OpenVPN lees dit as die beheerkanaal se gedeelde geheim, nie as 'n sertifikaat nie, nie as 'n wagfrase nie en nie as iets wat 'n TLS-biblioteek sou herken nie.

Dieselfde objektipe dien albei beheerkanaalfunksies. Met tls-auth het elke eweknie ook 'n rigting nodig sodat een kant se pakkette nie na hom teruggekaats kan word nie. Met tls-crypt versleutel en verifieer een gedeelde geheim die beheerkanaal in albei rigtings, wat die handdruk verberg sowel as beskerm.

Niks daarvan is geheime kennis nie, en die formaat is nie die punt nie. Die punt is dat die lêer presies moet pas by wat die leser verwag: kop, rywydte, slot nuwe reël en totale lengte. 'n Lêer wat een ry verkeerd is, laai as gemors of misluk heeltemal. Om twee eweknieë greep vir greep te vergelyk is dus 'n wettige eerste toets, en dit is vinniger as om een van die twee konfigurasielêers te lees.

Die ondersteunde manier om een te maak

Genereer die gewone statiese sleutel met die gereedskap wat dit sal gebruik, en verwys dan van albei kante daarna:

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

Die spelling van die opsie het oor tyd verander: ouer installasies uit die 2.4-era het 'n vorm met 'n aparte vlag voor die lêernaam gebruik, terwyl huidige boue die korter een aanvaar. Hoe dit ook al sy, die resulterende lêer is dieselfde soort objek, so die toets is of albei eweknieë identiese grepe het.

Die tweede generasie voeg struktuur by wat geen eksterne genereerder kan uitdink nie. 'n Bediener-sleutel word een keer geskep, en elke kliënt ontvang 'n toegedraaide sleutel wat daarvan afgelei is:

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

Wat die kliënt ontvang, is nie die bediener se eie sleutel gedupliseer nie. Dit is 'n toegedraaide objek met metadata wat net die bediener kan oopmaak, en daardie toedraaiing is die rede waarom 'n lêer per toestel herroep kan word sonder om enige ander toestel te raak. Hou die bediener-sleutel op die bediener en behandel dit as die wortel van daardie vertroue per toestel.

Waar handgemaakte grepe ineenstort

Om 256 ewekansige grepe as hex onder 'n korrekte kop te druk sou teoreties 'n statiese sleutellêer lewer wat laai. Dit bly 'n slegte idee. Elke formateringsdetail word 'n kans om materiaal te produseer wat by laai misluk of, erger, twee eweknieë met verskillende waardes laat wat hulself eers as 'n verifikasiefout openbaar.

Niks soortgelyks is met die v2-variant moontlik nie. 'n Toegedraaide kliëntsleutel bestaan net as uitset van die bediener se sleutelproses, en die bediener behou die materiaal wat nodig is om dit oop te maak. 'n Ewekansige klomp sal verwerp word of sal eenvoudig nie kan ontsyfer nie, en nie een van die twee boodskappe sal ewekansigheid noem nie.

Weergawe-versoenbaarheid lê bo-op dit alles. Die eerste generasie het 'n weergawe nodig wat dit aan albei kante ondersteun, en die tweede het weer 'n nuwer weergawe nodig. 'n Kliënt wat gebou is voordat die funksie bestaan het, kan nie 'n handdruk met 'n bediener voltooi wat net toegedraaide materiaal aanvaar nie, en die fout wat dit rapporteer, wys na die beheerkanaal eerder as na die weergawe.

Roteer sonder om almal uit te sluit

Om een gedeelde geheim te roteer is 'n koördinerings-oefening eerder as 'n tegniese een. Elke kliënt het die vervangings-lêer in die hand nodig voordat die bediener die vorige onttrek, en enige masjien wat nog die ou waarde hou, misluk op die oomblik dat dit gebeur. Moenie daardie rotasie in die middel van 'n werksdag begin nie.

Met die v2-reëling is rotasie per toestel: reik 'n nuwe toegedraaide sleutel vir een masjien uit en trek die ou een net vir daardie masjien terug. Dit is die hoofargument om oor te skakel sodra elke kliënt op 'n weergawe is wat dit ondersteun.

Lêertoestemmings hoort in dieselfde gesprek. Die sleutel behoort net leesbaar te wees vir die rekening wat die diens bestuur, en dit behoort nie in dieselfde bewaarplek te woon as die profiele wat dit beskerm nie. Die OpenVPN 2.6-verwysing dokumenteer die genereringsvorme en die sleutelmateriaal-afdelings, wat 'n beter bron is as 'n gekopieerde opdrag uit 'n forumplasing.