Kial openssl rand ne povas fari la ŝlosilon, kiun tls-crypt postulas

OpenSSL estas jam instalita, la gastiganto havas entropion, kaj generi ŝlosilon per ĝi ŝajnas la evidenta fuĝvojo. La eligotaĵo estos hazarda kaj sekreta kaj tute neuzebla, kaj la malsukceso aperas kiel eraro de la kontrola kanalo anstataŭ kiel io, kio mencias ŝlosilformon. Tiu misgvidado estas la multekosta parto, ĉar ĝi sendas homojn ekzameni siajn ĉifrojn. Tio, kion la VPN legas, estas specifa dosierstrukturo, ne arbitra bloko da bajtoj, kaj unu variaĵo de la funkcio tute ne povas esti produktita ekster la servilo.

Kio la dosiero sur la disko efektive devas esti

Statika ŝlosildosiero de OpenVPN estas teksto. Ĝi komenciĝas per komenta linio, kiu deklaras, kio ĝi estas, portas deksesumajn datumojn en vicoj de fiksa larĝo, kaj enhavas sume 256 bajtojn da ŝlosilmaterialo. OpenVPN legas ĝin kiel la komunan sekreton de la kontrola kanalo, ne kiel atestilon, ne kiel pasfrazon kaj ne kiel ion, kion TLS-biblioteko rekonus.

La sama objekttipo utilas por ambaŭ funkcioj de la kontrola kanalo. Ĉe tls-auth, ĉiu samtavolano ankaŭ bezonas direkton, por ke la pakoj de unu flanko ne povu esti reflektitaj reen al ĝi. Ĉe tls-crypt, unu komuna sekreto ĉifras kaj aŭtentikigas la kontrolan kanalon en ambaŭ direktoj, kio kaŝas la manpremon samkiel ĝi protektas ĝin.

Nenio el tio estas sekreta scio, kaj la formato ne estas la punkto. La punkto estas, ke la dosiero devas kongrui ekzakte kun tio, kion la leganto atendas: kaplinio, viclarĝo, fina linifino kaj totala longo. Dosiero, kiu maltrafas unu vicon, ŝargiĝas kiel rubaĵo aŭ simple malsukcesas. Kompari du samtavolanojn bajto post bajto do estas legitima unua testo, kaj ĝi estas pli rapida ol legi iun ajn el la du agordaj dosieroj.

La subtenata maniero fari unu

Generu la simplan statikan ŝlosilon per la ilo, kiu konsumos ĝin, kaj poste referencu ĝin el ambaŭ finoj:

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

La literumo de la opcio ŝanĝiĝis laŭlonge de la tempo: pli malnovaj instalaĵoj el la 2.4-epoko uzis formon kun aparta flago antaŭ la dosiernomo, dum nunaj konstruoj akceptas la pli mallongan. Ĉiel ajn, la rezulta dosiero estas la sama speco de objekto, do la kontrolo estas, ĉu ambaŭ samtavolanoj tenas identajn bajtojn.

La dua generacio aldonas strukturon, kiun neniu ekstera generatoro povas elpensi. Servila ŝlosilo kreiĝas unufoje, kaj ĉiu kliento ricevas ĉirkaŭvolvitan ŝlosilon derivitan el ĝi:

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

Tio, kion la kliento ricevas, ne estas la propra ŝlosilo de la servilo duobligita. Ĝi estas ĉirkaŭvolvita objekto portanta metadatumojn, kiujn nur la servilo povas malvolvi, kaj tiu ĉirkaŭvolvaĵo estas la kialo, kial dosiero por unu aparato povas esti revokita sen tuŝi iun ajn alian aparaton. Konservu la servilan ŝlosilon sur la servilo kaj traktu ĝin kiel la radikon de tiu fido por aparato.

Kie permane faritaj bajtoj paneas

Presi 256 hazardajn bajtojn kiel deksesumon sub ĝusta kaplinio teorie donus statikan ŝlosildosieron, kiu ŝargiĝas. Ĝi restas malbona ideo. Ĉiu formatada detalo fariĝas ŝanco produkti materialon, kiu malsukcesas ĉe ŝarĝo aŭ, pli malbone, lasas du samtavolanojn kun malsamaj valoroj, kiuj malkaŝiĝas nur kiel aŭtentikiga malsukceso.

Nenio ekvivalenta eblas kun la variaĵo v2. Ĉirkaŭvolvita klienta ŝlosilo ekzistas nur kiel eligotaĵo de la servila ŝlosilprocezo, kaj la servilo retenas la materialon bezonatan por malvolvi ĝin. Hazardeca bloko estos malakceptita aŭ simple malsukcesos malĉifri, kaj neniu el la du mesaĝoj mencios hazarecon.

Versia kongruo sidas sur ĉio ĉi. La unua generacio bezonas eldonon, kiu subtenas ĝin ĉe ambaŭ finoj, kaj la dua bezonas denove pli novan eldonon. Kliento konstruita antaŭ ol la funkcio ekzistis ne povas kompletigi manpremon kun servilo, kiu akceptas nur ĉirkaŭvolvitan materialon, kaj la malsukceso, kiun ĝi raportas, montras al la kontrola kanalo anstataŭ al la versio.

Rotacii sen ŝlosi ĉiujn ekstere

Rotacii unu komunan sekreton estas kunordiga ekzerco, ne teknika. Ĉiu kliento bezonas la anstataŭan dosieron enmane antaŭ ol la servilo retiras la antaŭan, kaj iu ajn maŝino, kiu ankoraŭ tenas la malnovan valoron, malsukcesas en tiu momento. Ne komencu tiun rotacion meze de labortago.

Kun la aranĝo v2, la rotacio estas por aparato: eldonu novan ĉirkaŭvolvitan ŝlosilon por unu maŝino kaj retiru la malnovan nur por tiu maŝino. Tio estas la ĉefa argumento por transiri, kiam ĉiu kliento estas sur eldono, kiu subtenas ĝin.

Dosierpermesoj apartenas al la sama konversacio. La ŝlosilo devus esti legebla nur de la konto, kiu rulas la servon, kaj ĝi ne devus loĝi en la sama deponejo kiel la profiloj, kiujn ĝi protektas. La OpenVPN 2.6-referenco dokumentas la generajn formojn kaj la sekciojn pri ŝlosilmaterialo, kio estas pli bona fonto ol kopiita komando el forumafŝaĵo.