Bakit hindi kayang gawin ng openssl rand ang susi na hinihingi ng tls-crypt

Naka-install na ang OpenSSL, may entropy ang host, at ang paggawa ng susi gamit ito ay parang halatang shortcut. Ang output ay magiging random at lihim at ganap na walang gamit, at ang pagkabigo ay darating bilang error ng control channel sa halip na isang bagay na nagbabanggit ng key format. Ang maling direksyong iyon ang mahal na bahagi, dahil ipinapadala nito ang mga tao na siyasatin ang kanilang mga cipher. Ang binabasa ng VPN ay isang partikular na istruktura ng file, hindi isang arbitrary na bloke ng bytes, at ang isang variant ng feature ay hindi kayang gawin sa labas ng server.

Ano talaga ang dapat na maging file sa disk

Ang static key file ng OpenVPN ay teksto. Nagsisimula ito sa isang linya ng komento na nagpapahayag kung ano ito, nagdadala ng hex data sa mga hilera na may fixed na lapad, at may kabuuang 256 bytes na key material. Binabasa ito ng OpenVPN bilang shared secret ng control channel, hindi bilang certificate, hindi bilang passphrase at hindi bilang anumang makikilala ng TLS library.

Ang parehong uri ng object ay naglilingkod sa dalawang feature ng control channel. Sa tls-auth, kailangan din ng bawat peer ng direksyon upang hindi maipabalik sa kanya ang mga packet ng isang panig. Sa tls-crypt, isang shared secret ang nag-encrypt at nagpapatunay ng control channel sa dalawang direksyon, na nagtatago ng handshake at nagpoprotekta rin dito.

Wala sa mga iyon ang lihim na kaalaman, at ang format ay hindi ang punto. Ang punto ay kailangang tumugma nang eksakto ang file sa inaasahan ng nagbabasa: header, lapad ng hilera, huling newline at kabuuang haba. Ang file na isang hilera ang layo ay naglo-load bilang basura o ganap na nabibigo. Kaya ang paghahambing ng dalawang peer byte sa byte ay isang lehitimong unang pagsubok, at mas mabilis ito kaysa sa pagbasa ng alinman sa dalawang configuration file.

Ang sinusuportahang paraan ng paggawa ng isa

Gumawa ng simpleng static key gamit ang tool na gagamit nito, pagkatapos ay i-reference ito mula sa dalawang dulo:

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

Nagbago ang spelling ng option sa paglipas ng panahon: ginamit ng mga lumang installation noong panahon ng 2.4 ang anyo na may hiwalay na flag bago ang filename, habang tinatanggap ng kasalukuyang build ang mas maikli. Alinman sa dalawa, ang resultang file ay parehong uri ng object, kaya ang tsek ay kung may magkatulad na bytes ang dalawang peer.

Ang ikalawang henerasyon ay nagdaragdag ng istrukturang hindi kayang imbentuhin ng anumang panlabas na generator. Ang server key ay ginagawa isang beses, at ang bawat client ay tumatanggap ng nakabalot na susi na hinango mula rito:

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

Ang tinatanggap ng client ay hindi ang sariling susi ng server na kinopya. Ito ay isang nakabalot na object na nagdadala ng metadata na tanging server lang ang makakabukas, at ang balot na iyon ang dahilan kung bakit ang file para sa isang device ay maaaring bawiin nang hindi hinahawakan ang anumang ibang device. Itago ang server key sa server at ituring ito bilang ugat ng pagtitiwalang iyon sa bawat device.

Saan nasisira ang mga byte na ginawa sa kamay

Ang pag-print ng 256 random na byte bilang hex sa ilalim ng tamang header ay teoretikal na magbubunga ng static key file na naglo-load. Mahinang ideya pa rin ito. Ang bawat detalye ng pag-format ay nagiging pagkakataon na gumawa ng materyal na nabibigo sa pag-load o, mas masahol pa, nag-iiwan ng dalawang peer na may magkaibang value na lumilitaw lamang bilang pagkabigo sa pagpapatunay.

Walang katumbas ang posible sa variant na v2. Ang nakabalot na client key ay umiiral lamang bilang output ng proseso ng server key, at itinatago ng server ang materyal na kailangan upang mabalot ito. Ang random na bloke ay tatanggihan o basta hindi makakapag-decrypt, at wala sa dalawang mensahe ang magbabanggit ng randomness.

Ang compatibility ng bersyon ay nasa ibabaw ng lahat ng ito. Ang unang henerasyon ay nangangailangan ng release na sumusuporta rito sa dalawang dulo, at ang pangalawa ay nangangailangan muli ng mas bagong release. Ang client na ginawa bago umiral ang feature ay hindi makakumpleto ng handshake sa server na tumatanggap lamang ng nakabalot na materyal, at ang pagkabigong iniuulat nito ay tumuturo sa control channel sa halip na sa bersyon.

Pag-ikot nang hindi kinakandado ang lahat sa labas

Ang pag-ikot ng isang shared secret ay pagsasanay sa koordinasyon, hindi teknikal. Kailangang nasa kamay ng bawat client ang kapalit na file bago bawiin ng server ang nauna, at anumang makina na mayroon pa ng lumang value ay nabibigo sa sandaling mangyari iyon. Huwag simulan ang pag-ikot na iyon sa kalagitnaan ng araw ng trabaho.

Sa kaayusang v2, ang pag-ikot ay bawat device: maglabas ng bagong nakabalot na susi para sa isang makina at iretiro ang luma para sa makinang iyon lamang. Iyon ang pangunahing argumento para lumipat kapag ang bawat client ay nasa release na sumusuporta rito.

Ang mga pahintulot ng file ay kabilang sa parehong usapan. Dapat mabasa lamang ang susi ng account na nagpapatakbo ng serbisyo, at hindi ito dapat tumira sa parehong repository ng mga profile na pinoprotektahan nito. Ang OpenVPN 2.6 reference ay nagdodokumento ng mga anyo ng paggawa at ng mga seksyon ng key material, na mas mahusay na pinagmulan kaysa sa kopyadong command mula sa post sa forum.