tls-auth proti tls-crypt: kaj vsaka možnost v OpenVPN ščiti

Obe možnosti uporabljata skupno datoteko s ključem in obe otežujeta ponarejanje prometa rokovanja, zato ju obravnavamo kot dve imeni iste funkcije. Nista. Ena podpiše nadzorne pakete, druga jih tudi šifrira, in nobena nima nič skupnega s šifro, ki ščiti vaše podatke.

Ta razlika je pomembna, ko se profil ne more povezati, ko varnostni pregled vpraša, kaj ključ ščiti, in ko nekdo domneva, da dodatna datoteka naredi tunel šifriran na nek nedoločen način.

Kaj skupni ključ v resnici ščiti

Ključ, ki ga te možnosti uporabljajo, pripada nadzornemu kanalu: izmenjavi, ki se pogaja o parametrih, dokazuje identitete in izpelje ključe podatkov. To je vnaprej deljena skrivnost, ki jo morata imeti oba konca, preden se rokovanje lahko nadaljuje. Ker stoji pred preverjanjem identitete, napačen ključ ustavi pogovor prej, kot bi ga napačno geslo. Ta vrstni red pojasnjuje, zakaj je način odpovedi tako tih.

tls-auth uporablja to skrivnost za izračun HMAC nad nadzornimi paketi. Paket brez veljavnega podpisa se zavrže, preden doseže dražjo obdelavo TLS, zato to možnost pogosto opisujejo kot prvi filter in ne kot nadomestilo za TLS.

tls-crypt gre dlje in zaščiteni nadzorni promet poleg overjanja tudi šifrira. Vsebina potrdil, dogovorjena imena šifer in druge podrobnosti rokovanja niso več vidne v omrežju, in opazovalec brez ključa ne more videti niti, katera različica TLS se poskuša. Za postavitev, ki se boji razkriti svoj odtis VPN, je ta lastnost glavni razlog za izbiro. Še vedno je skupna skrivnost skupine, ne poverilnica za posameznega uporabnika.

Noben mehanizem ne izdaja identitet. Skupni ključ je skupna skrivnost skupine, in vsak, ki ga ima, lahko zadovolji to plast preverjanja.

Kje se možnosti razlikujeta

Opazna razlika je, kaj vidi opazovalec. Z tls-auth je rokovanje vidno, a brez ključa ni preverljivo. Z tls-crypt je rokovanje neprosojno za vsakogar, ki ključa nima.

Tudi konfiguracija se razlikuje. tls-auth se uporablja z vrednostjo smeri, zato ena stran uporabi eno polovico ključnega gradiva, druga pa drugo. tls-crypt uporablja en ključ v obeh smereh, zato direktiva smeri ni del njegove zasnove.

V sodobnih izdajah se možnosti medsebojno izključujeta. Profil naj nosi eno od njiju, ne obeh, strežnik in odjemalec pa se morata dogovoriti, katero, z enakim ključnim gradivom. Ohranjanje stare direktive ob novi je pogost ostanek selitve. Odstranite neaktivno, da bo naslednji bralec vedel, katera plast dejansko velja.

Novejša različica, tls-crypt-v2, veže vsakega odjemalca na njegov lastni zaviti ključ, tako da preklic enega odjemalca ne zahteva ponovne izdaje skupinskega ključa. Vredno je vedeti, a je druga možnost in ni sopomenka za nobeno od teh dveh.

Zakaj je neujemanje videti, kot da se nič ne dogaja

Ko se skupno gradivo ne ujema, nasprotna stran pakete zavrže, ne da bi pošiljatelju povedala zakaj. Nobene napake overjanja ni za brati, ker paket nikoli ni dosegel plasti, ki bi jo ustvarila.

Odjemalec poskusi znova, strežnik ne reče ničesar, in simptom je videti kot omrežna težava. Potem ljudje znova zaženejo storitev, znova vtipkajo geslo računa ali odstranijo zaščitno direktivo, da bi jo «preizkusili», kar spremeni postavitev, namesto da bi jo diagnosticiralo.

V dnevniku strežnika preberite prvo pritožbo na ravni paketov, ne zadnje vrstice ponovnega poskusa. Potrdite, da obe strani nosita isto možnost z enakim ključnim gradivom in da ključna datoteka ni bila znova ustvarjena le na eni strani.

Odstranitev direktive ni varna popravka. Izklopi plast zaščite za vsakega odjemalca, in tunel, ki potem deluje, dokazuje le, da je bila ta plast neujemanje.

Kaj je še treba nastaviti ločeno

Te možnosti ne preverjajo, kdo je nasprotna stran. Preverjanje potrdil, sidro zaupanja in pričakovano ime strežnika ostajajo ločene zahteve, in nobena od njih ne postane neobvezna zaradi skupnega ključa.

Prav tako ne izbereta šifre podatkov. To je ločeno pogajanje, ki ga usmerjajo nastavitve podatkovnega kanala na obeh straneh, in tunel, zaščiten z tls-crypt, lahko še vedno uporabi šifro, ki je niste nameravali.

Nazadnje, sam skupni ključ potrebuje ravnanje. Obravnavajte ga kot skrivnost, razdelite ga po odobrenem kanalu in ga zamenjajte, ko odide kdorkoli, ki ga je imel. Ker je skupen, je njegova izpostavljenost izpostavljenost vsakega konca, ki ga uporablja.