tls-auth kumpara sa tls-crypt: ano ang pinoprotektahan ng bawat isa sa OpenVPN

Gumagamit ang dalawang opsyon ng isang shared key file at parehong ginagawang mas mahirap pekein ang handshake traffic, kaya tinuturing silang dalawang pangalan ng isang feature. Hindi sila ganoon. Nilalagdaan ng isa ang mga control packet, ini-encrypt din ng isa, at wala sa dalawa ang may kaugnayan sa cipher na nagpoprotekta sa iyong payload.

Mahalaga ang pagkakaibang iyon kapag nabigo ang isang profile na kumonekta, kapag tinanong ng security review kung ano ang pinoprotektahan ng key, at kapag may nag-aakalang ginagawang naka-encrypt ng extra file ang tunnel sa isang hindi malinaw na paraan.

Ano ba talaga ang pinoprotektahan ng shared key

Ang key na ginagamit ng mga opsyong ito ay kabilang sa control channel: ang palitan na nag-uusap sa mga parameter, nagpapatunay ng pagkakakilanlan at kumukuha ng data keys. Isa itong secret na pinagsaluhan nang maaga na dapat taglayin ng dalawang dulo bago magpatuloy ang handshake. Dahil nauuna ito sa mga pagsusuri ng pagkakakilanlan, mas maaga nitong pinapatigil ang usapan kaysa sa isang maling password. Ipinapaliwanag ng pagkakasunod-sunod na iyon kung bakit napakatahimik ng failure mode.

tls-auth ay gumagamit ng secret na iyon para kalkulahin ang HMAC sa mga control packet. Ang packet na walang valid na signature ay itinatapon bago pa ito umabot sa mas magastos na TLS processing, kaya madalas ilarawan ang opsyong ito bilang unang filter at hindi bilang kapalit ng TLS.

tls-crypt ay lumalampas pa doon sa pamamagitan ng pag-encrypt sa protektadong control traffic bukod sa pagpapatunay nito. Hindi na nakikita sa network ang nilalaman ng mga sertipiko, ang napagkasunduang pangalan ng cipher at iba pang detalye ng handshake, at ang isang tagamasid na walang key ay hindi man lang makikita kung aling bersyon ng TLS ang sinusubukan. Para sa deployment na natatakot ibunyag ang fingerprint ng VPN nito, ang katangiang iyon ang pangunahing dahilan para piliin ito. Secret pa rin ito ng grupo, hindi kredensyal ng bawat user.

Wala sa mga mekanismo ang naglalabas ng pagkakakilanlan. Ang shared key ay secret ng grupo, at kahit sino ang mayroon nito ay makakasapat sa layer na iyon ng pagsusuri.

Saan nagkakaiba ang dalawang opsyon

Ang nakikitang pagkakaiba ay kung ano ang nakikita ng isang tagamasid. Sa tls-auth, nakikita ang handshake ngunit hindi maipapatunay nang walang key. Sa tls-crypt, ang handshake ay malabo para sa sinumang walang key.

Nagkakaiba rin ang configuration. Ginagamit ang tls-auth kasama ng value ng direksyon, kaya isang kalahati ng key material ang gamit ng isang panig at ang kabilang kalahati naman ng isa pa. Gumagamit ang tls-crypt ng isang key sa dalawang direksyon, kaya ang direktiba ng direksyon ay hindi bahagi ng kaayusan nito.

Sa mga modernong release, ang dalawang opsyon ay magkasalungat. Dapat isa lang sa mga ito ang taglayin ng profile, hindi pareho, at kailangang magkasundo ang server at client kung alin, na may tugmang key material. Ang pag-iiwan ng lumang direktiba tabi ng bago ay karaniwang nalalabi ng migration. Alisin ang hindi aktibo upang malaman ng susunod na mambabasa kung aling layer ang talagang umiiral.

Isang mas bagong variant, ang tls-crypt-v2, ay nagbubuklod sa bawat client sa sarili nitong nakabalot na key, kaya hindi kailangang muling ilabas ang group key kapag binawi ang isang client. Sulit itong malaman, ngunit iba itong opsyon at hindi kasingkahulugan ng alinman sa dalawa dito.

Bakit ang hindi pagkakatugma ay mukhang walang nangyayari

Kapag hindi tugma ang shared material, itinatapon ng kabilang dulo ang mga packet nang hindi sinasabi sa nagpadala kung bakit. Walang error sa authentication na mababasa, dahil hindi kailanman umabot ang packet sa layer na gagawa nito.

Inuulit ng client, walang sinasabi ang server, at ang sintomas ay mukhang problema sa network. Pagkatapos ay ini-restart ng mga tao ang serbisyo, muling tina-type ang password ng account, o inaalis ang direktiba ng proteksyon para «subukan» ito, na binabago ang deployment sa halip na i-diagnose ito.

Basahin sa log ng server ang unang reklamo sa antas ng packet, hindi ang huling linya ng muling pagsubok. Tiyakin na pareho ang opsyon sa magkabilang panig na may identical na key material at hindi na-regenerate ang key file sa isang panig lamang.

Ang pag-alis ng direktiba ay hindi ligtas na pagkukumpuni. Pinapatay nito ang isang layer ng proteksyon para sa bawat client, at ang tunnel na gagana pagkatapos ay nagpapatunay lamang na ang layer na iyon ang hindi pagkakatugma.

Ano ang kailangan pang i-configure nang hiwalay

Hindi bineberipika ng mga opsyong ito kung sino ang kabilang dulo. Ang validation ng sertipiko, ang trust anchor at ang inaasahang pangalan ng server ay nananatiling hiwalay na mga kinakailangan, at wala sa mga ito ang nagiging opsyonal dahil may shared key.

Hindi rin nila pinipili ang cipher ng data. Iyon ay hiwalay na negosasyon na kinokontrol ng mga setting ng data channel sa magkabilang dulo, at ang tunnel na protektado ng tls-crypt ay maaari pa ring gumamit ng cipher na hindi mo intensyon.

Panghuli, ang shared key mismo ay nangangailangan ng pag-aalaga. Ituring itong secret, ipamahagi sa isang aprubadong channel, at palitan kapag umalis ang sinumang may hawak nito. Dahil pinagsasaluhan ito, ang pagkakalantad nito ay pagkakalantad ng bawat dulo na gumagamit nito.