De ce openssl rand nu poate crea cheia pe care o vrea tls-crypt

OpenSSL este deja instalat, gazda are entropie, iar generarea unei chei cu el pare scurtătura evidentă. Rezultatul va fi aleatoriu și secret și complet inutilizabil, iar eșecul apare ca eroare a canalului de control în loc de ceva care menționează un format de cheie. Tocmai această direcționare greșită este partea costisitoare, pentru că trimite oamenii să-și inspecteze cifrurile. Ce citește VPN-ul este o structură de fișier anume, nu un bloc arbitrar de octeți, iar una dintre variantele funcției nu poate fi produsă deloc în afara serverului.

Ce trebuie să fie de fapt fișierul de pe disc

Un fișier de cheie statică OpenVPN este text. Începe cu o linie de comentariu care declară ce este, poartă date hexazecimale în rânduri de lățime fixă și totalizează 256 de octeți de material de cheie. OpenVPN îl citește ca secretul partajat al canalului de control, nu ca certificat, nu ca frază de acces și nu ca ceva ce o bibliotecă TLS ar recunoaște.

Același tip de obiect servește ambele funcții ale canalului de control. Cu tls-auth, fiecare partener are nevoie și de o direcție, astfel încât pachetele unei părți să nu poată fi reflectate înapoi spre el. Cu tls-crypt, un singur secret partajat criptează și autentifică canalul de control în ambele direcții, ceea ce ascunde handshake-ul și, totodată, îl protejează.

Nimic din toate acestea nu este cunoaștere secretă, iar formatul nu este ideea. Ideea este că fișierul trebuie să corespundă exact cu ceea ce așteaptă cititorul: antet, lățimea rândului, linia nouă finală și lungimea totală. Un fișier care diferă cu un rând se încarcă drept gunoi sau eșuează complet. Compararea a doi parteneri octet cu octet este, așadar, un prim test legitim și este mai rapid decât citirea oricăruia dintre cele două fișiere de configurare.

Modul acceptat de a crea unul

Generați cheia statică simplă cu instrumentul care o va consuma, apoi referiți-o de la ambele capete:

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

Ortografia opțiunii s-a schimbat de-a lungul timpului: instalările mai vechi din era 2.4 foloseau o formă cu un steag separat înainte de numele fișierului, în timp ce compilările actuale o acceptă pe cea mai scurtă. În orice caz, fișierul rezultat este același tip de obiect, așa că verificarea este dacă ambii parteneri au octeți identici.

A doua generație adaugă o structură pe care niciun generator extern nu o poate inventa. O cheie de server este creată o singură dată, iar fiecare client primește o cheie înfășurată derivată din ea:

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

Ceea ce primește clientul nu este propria cheie a serverului duplicată. Este un obiect înfășurat care poartă metadate pe care doar serverul le poate desface, iar această înfășurare este motivul pentru care un fișier pentru un singur dispozitiv poate fi revocat fără a atinge niciun alt dispozitiv. Păstrați cheia serverului pe server și tratați-o ca rădăcina acelei încrederi pe dispozitiv.

Unde se rupe materialul făcut manual

Tipărirea a 256 de octeți aleatori ca hexazecimal sub un antet corect ar produce, în teorie, un fișier de cheie statică care se încarcă. Rămâne o idee proastă. Fiecare detaliu de formatare devine o șansă de a produce material care eșuează la încărcare sau, mai rău, lasă doi parteneri cu valori diferite care se dezvăluie doar ca eșec de autentificare.

Nimic echivalent nu este posibil cu varianta v2. O cheie de client înfășurată există doar ca rezultat al procesului de cheie al serverului, iar serverul păstrează materialul necesar pentru a o desface. Un blob aleatoriu va fi respins sau pur și simplu nu va reuși să decripteze, și niciunul dintre cele două mesaje nu va menționa aleatorietatea.

Compatibilitatea versiunilor stă deasupra tuturor acestora. Prima generație are nevoie de o versiune care o acceptă la ambele capete, iar a doua are nevoie din nou de o versiune mai nouă. Un client construit înainte de existența funcției nu poate finaliza un handshake cu un server care acceptă doar material înfășurat, iar eșecul raportat indică canalul de control, nu versiunea.

Rotire fără a încuia pe toată lumea afară

Rotirea unui singur secret partajat este un exercițiu de coordonare, nu tehnic. Fiecare client are nevoie de fișierul de înlocuire în mână înainte ca serverul să-l retragă pe cel anterior, iar orice mașină care mai are valoarea veche eșuează în acel moment. Nu începeți acea rotire la mijlocul unei zile de lucru.

Cu aranjamentul v2, rotirea este pe dispozitiv: emiteți o cheie înfășurată nouă pentru o mașină și retrageți-o pe cea veche doar pentru acea mașină. Acesta este argumentul principal pentru migrare odată ce fiecare client este pe o versiune care o acceptă.

Permisiunile fișierelor fac parte din aceeași conversație. Cheia ar trebui să fie lizibilă doar de contul care rulează serviciul și nu ar trebui să locuiască în același depozit ca profilurile pe care le protejează. Referința OpenVPN 2.6 documentează formele de generare și secțiunile despre materialul cheii, ceea ce este o sursă mai bună decât o comandă copiată dintr-o postare pe forum.