tls-auth prieš tls-crypt: ką kiekvienas saugo OpenVPN
tls-auth pasirašo valdymo paketus, tls-crypt juos dar ir paslepia. Nė vienas nepakeičia sertifikatų tikrinimo ar duomenų šifro, o neatitikimas atrodo kaip tyla.
Abi parinktys naudoja bendrą raktų failą ir abi apsunkina rankos paspaudimo srauto klastojimą, todėl jos laikomos dviem tos pačios funkcijos pavadinimais. Taip nėra. Viena pasirašo valdymo paketus, kita juos dar ir šifruoja, ir nė viena neturi nieko bendra su šifru, kuris saugo jūsų duomenis.
Šis skirtumas svarbus, kai profilis negali prisijungti, kai saugumo patikra klausia, ką saugo raktas, ir kai kas nors mano, kad papildomas failas padaro tunelį užšifruotą kažkaip neapibrėžtai.
Ką iš tikrųjų saugo bendras raktas
Šių parinkčių naudojamas raktas priklauso valdymo kanalui: mainams, kurie derina parametrus, įrodo tapatybes ir išveda duomenų raktus. Tai iš anksto bendrinama paslaptis, kurią turi turėti abu galai, kad rankos paspaudimas galėtų tęstis. Kadangi ji yra prieš tapatybės patikras, neteisingas raktas sustabdo pokalbį anksčiau nei tai padarytų neteisingas slaptažodis. Ši tvarka paaiškina, kodėl gedimo režimas toks tylus.
tls-auth naudoja šią paslaptį HMAC valdymo paketams apskaičiuoti. Paketas be galiojančio parašo atmetamas dar nepasiekęs brangesnio TLS apdorojimo, todėl ši parinktis dažnai apibūdinama kaip pirmasis filtras, o ne TLS pakaitalas.
tls-crypt eina toliau ir šifruoja apsaugotą valdymo srautą, be to, kad jį autentifikuoja. Sertifikatų turinys, suderinti šifrų pavadinimai ir kitos rankos paspaudimo detalės nebėra matomi tinkle, o stebėtojas be rakto net negali pamatyti, kuri TLS versija bandoma. Diegimui, kuris bijo atskleisti savo VPN pirštų atspaudą, ši savybė yra pagrindinė priežastis ją pasirinkti. Ji vis tiek yra grupinė paslaptis, o ne kiekvieno naudotojo kredencialas.
Nė vienas mechanizmas neišduoda tapatybių. Bendras raktas yra grupinė paslaptis, ir kiekvienas, kas jį turi, gali įvykdyti tą patikros sluoksnį.
Kuo skiriasi abi parinktys
Stebimas skirtumas yra tai, ką mato stebėtojas. Su tls-auth rankos paspaudimas matomas, bet be rakto nepatikrinamas. Su tls-crypt rankos paspaudimas nepermatomas visiems, kas neturi rakto.
Konfigūracija taip pat skiriasi. tls-auth naudojamas su krypties reikšme, todėl viena pusė naudoja vieną raktų medžiagos pusę, o kita pusė kitą. tls-crypt naudoja vieną raktą abiem kryptimis, todėl krypties direktyva nėra jo sandaros dalis.
Šiuolaikiniuose leidimuose abi parinktys viena kitą išskiria. Profilis turi turėti vieną iš jų, o ne abi, o serveris ir klientas turi sutarti, kurią, su atitinkančia raktų medžiaga. Senos direktyvos laikymas šalia naujos yra įprastas migracijos likutis. Pašalinkite neaktyvią, kad kitas skaitytojas žinotų, kuris sluoksnis iš tikrųjų galioja.
Naujesnis variantas, tls-crypt-v2, susieja kiekvieną klientą su jo paties apvyniotu raktu, kad vieno kliento atšaukimas nereikalautų iš naujo išduoti grupinio rakto. Verta žinoti, bet tai kita parinktis ir ne jų dviejų sinonimas.
Kodėl neatitikimas atrodo lyg nieko nevyktų
Kai bendra medžiaga nesutampa, kita pusė atmeta paketus nepasakydama siuntėjui kodėl. Nėra klaidų autentifikavimo, kuriuos būtų galima perskaityti, nes paketas niekada nepasiekė sluoksnio, kuris jį sukurtų.
Klientas bando dar kartą, serveris nieko nesako, o simptomas atrodo kaip tinklo problema. Tada žmonės perkrauna paslaugą, iš naujo įveda paskyros slaptažodį arba pašalina apsaugos direktyvą, kad ją «išbandytų», o tai pakeičia diegimą, o ne diagnozuoja jį.
Serverio žurnale skaitykite pirmąjį paketo lygio nusiskundimą, o ne paskutinę kartojimo eilutę. Patvirtinkite, kad abi pusės turi tą pačią parinktį su identiška raktų medžiaga ir kad raktų failas nebuvo pergeneruotas tik vienoje pusėje.
Direktyvos pašalinimas nėra saugus remontas. Jis išjungia apsaugos sluoksnį kiekvienam klientui, o vėliau veikiantis tunelis įrodo tik tai, kad tas sluoksnis buvo neatitikimas.
Ką dar reikia sukonfigūruoti atskirai
Šios parinktys netikrina, kas yra kita pusė. Sertifikatų patvirtinimas, pasitikėjimo inkaras ir laukiamas serverio vardas lieka atskirais reikalavimais, ir nė vienas jų netampa neprivalomas dėl bendro rakto.
Jos taip pat nepasirenka duomenų šifro. Tai atskiros derybos, kurias valdo abiejų pusių duomenų kanalo nustatymai, ir tls-crypt apsaugotas tunelis vis tiek gali naudoti šifrą, kurio neketinote.
Galiausiai pats bendras raktas reikalauja priežiūros. Elkitės su juo kaip su paslaptimi, platinkite jį patvirtintu kanalu ir pakeiskite, kai kas nors, kas jį turėjo, išeina. Kadangi jis bendras, jo atskleidimas yra kiekvieno jį naudojančio galo atskleidimas.