Kodėl openssl rand negali sukurti rakto, kurio nori tls-crypt

OpenSSL jau įdiegtas, hostas turi entropijos, ir raktą juo generuoti atrodo akivaizdus trumpiausias kelias. Išvestis bus atsitiktinė ir slapta ir visiškai netinkama naudoti, o klaida pasirodys kaip valdymo kanalo klaida, o ne kaip kažkas, kas užsimena apie rakto formatą. Būtent šis klaidinimas yra brangioji dalis, nes jis nukreipia žmones tikrinti savo šifrų. Tai, ką skaito VPN, yra konkreti failo struktūra, o ne savavališkas baitų blokas, ir vieno šios funkcijos varianto išvis neįmanoma pagaminti už serverio ribų.

Koks iš tikrųjų turi būti failas diske

OpenVPN statinio rakto failas yra tekstas. Jis prasideda komentaro eilute, kuri nurodo, kas tai yra, neša šešioliktainius duomenis fiksuoto pločio eilutėse ir iš viso sudaro 256 baitus raktinės medžiagos. OpenVPN jį skaito kaip bendrą valdymo kanalo paslaptį, ne kaip sertifikatą, ne kaip slaptafrazę ir ne kaip kažką, ką atpažintų TLS biblioteka.

Tas pats objekto tipas tarnauja abiem valdymo kanalo funkcijoms. Su tls-auth kiekvienam partneriui taip pat reikia krypties, kad vienos pusės paketai negalėtų būti atspindėti atgal į ją. Su tls-crypt viena bendra paslaptis šifruoja ir autentifikuoja valdymo kanalą abiem kryptimis, o tai paslepia rankos paspaudimą ir kartu jį apsaugo.

Niekas iš to nėra slaptos žinios, ir formatas nėra esmė. Esmė ta, kad failas turi tiksliai atitikti tai, ko tikisi skaitytojas: antraštė, eilutės plotis, baigiamasis naujos eilutės simbolis ir bendras ilgis. Viena eilute nepataikytas failas įkeliamas kaip šiukšlės arba visiškai nepavyksta. Todėl dviejų partnerių palyginimas baitas po baito yra teisėtas pirmasis testas, ir jis greitesnis nei bet kurio iš dviejų konfigūracijos failų skaitymas.

Palaikomas būdas vieną pasigaminti

Sugeneruokite paprastą statinį raktą įrankiu, kuris jį naudos, tada nurodykite jį iš abiejų galų:

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

Parinkties rašyba laikui bėgant keitėsi: senesnės 2.4 eros diegtys naudojo formą su atskira vėliavėle prieš failo vardą, o dabartinės versijos priima trumpesnę. Bet kuriuo atveju gaunamas failas yra to paties tipo objektas, todėl tikrinama, ar abu partneriai turi identiškus baitus.

Antroji karta prideda struktūrą, kurios negali sugalvoti joks išorinis generatorius. Serverio raktas sukuriamas vieną kartą, ir kiekvienas klientas gauna iš jo išvestą apvyniotą raktą:

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

Tai, ką gauna klientas, nėra paties serverio rakto kopija. Tai apvyniotas objektas su metaduomenimis, kuriuos gali atvynioti tik serveris, ir būtent šis apvyniojimas yra priežastis, kodėl vieno įrenginio failą galima atšaukti neliečiant jokio kito įrenginio. Laikykite serverio raktą serveryje ir traktuokite jį kaip to pasitikėjimo kiekvienu įrenginiu šaknį.

Kur lūžta rankomis padaryti baitai

Atspausdinus 256 atsitiktinius baitus kaip šešioliktainius po teisinga antrašte, teoriškai gautųsi įkeliamas statinio rakto failas. Tai vis tiek bloga idėja. Kiekviena formatavimo detalė tampa galimybe pagaminti medžiagą, kuri nepavyksta įkeliant arba, dar blogiau, palieka du partnerius su skirtingomis reikšmėmis, kurios atsiskleidžia tik kaip autentifikavimo klaida.

Su v2 variantu nieko panašaus neįmanoma. Apvyniotas kliento raktas egzistuoja tik kaip serverio rakto proceso išvestis, ir serveris saugo medžiagą, reikalingą jam atvynioti. Atsitiktinis blokas bus atmestas arba tiesiog nepavyks jo iššifruoti, ir nė vienas iš dviejų pranešimų neužsimins apie atsitiktinumą.

Versijų suderinamumas yra virš viso to. Pirmajai kartai reikia leidimo, kuris ją palaiko abiejuose galuose, o antrajai vėl reikia naujesnio leidimo. Klientas, pastatytas prieš atsirandant funkcijai, negali užbaigti rankos paspaudimo su serveriu, kuris priima tik apvyniotą medžiagą, ir jo pranešama klaida nurodo valdymo kanalą, o ne versiją.

Rotacija neužrakinant visų lauke

Vienos bendros paslapties rotacija yra koordinacijos pratimas, o ne techninis. Kiekvienas klientas turi turėti pakaitinį failą rankoje prieš serveriui atšaukiant ankstesnį, ir bet kuri mašina, kuri vis dar turi seną reikšmę, nepavyksta tą akimirką. Nepradėkite šios rotacijos darbo dienos viduryje.

Su v2 išdėstymu rotacija vykdoma pagal įrenginį: išduokite naują apvyniotą raktą vienai mašinai ir išveskite seną tik tai mašinai. Tai pagrindinis argumentas pereiti, kai kiekvienas klientas yra leidime, kuris tai palaiko.

Failo teisės priklauso tam pačiam pokalbiui. Raktas turėtų būti skaitomas tik tos paskyros, kuri paleidžia paslaugą, ir neturėtų gyventi tame pačiame saugykloje kaip profiliai, kuriuos jis saugo. OpenVPN 2.6 žinynas dokumentuoja generavimo formas ir raktinės medžiagos skyrius, o tai geresnis šaltinis nei nukopijuota komanda iš forumo įrašo.