Fișier DH sau cheie tls-auth? Distingerea a două fișiere OpenVPN

Două fișiere, două directive și obiceiul de a le numi pe amândouă după lucrul pe care îl configurează. Așa ajunge un dh.pem pe o linie tls-auth și clientul eșuează cu un mesaj despre un format de cheie neașteptat. Decizia din fața ta nu este care fișier este mai puternic. Este ce rol are nevoie de fapt implementarea, și trei condiții o rezolvă: ce schimb de chei va negocia stiva ta TLS, dacă vrei autentificarea canalului de control și dacă materialul trebuie să rămână secret.

Răspunde la ele în ordine și întrebarea fișierului se răspunde singură. Dacă le sari, numele directivelor încep să pară interschimbabile, iar de aici provine exact eroarea.

Citește eticheta înainte de numele fișierului

Prima linie a fișierului spune mai mult decât numele, pentru că un nume este o convenție umană, iar eticheta este produsă de instrument. Parametrii Diffie-Hellman poartă o etichetă PEM BEGIN DH PARAMETERS. O cheie statică OpenVPN este o structură complet diferită, cu propriul antet și propria încărcătură hexazecimală.

Redenumirea nu convertește nimic. Un fișier de parametri numit ta.key rămâne parametri, iar o cheie statică numită dh.pem rămâne cheie statică; parserul citește conținutul și respinge nepotrivirea. Verifică înainte de a edita profilul:

head -n 1 dh.pem
head -n 1 ta.key

Trei condiții care decid de ce fișier ai nevoie

Prima condiție este schimbul. Un handshake Diffie-Hellman pe câmp finit are nevoie de un grup, iar directiva dh este locul unde serverul numește parametrii pentru el. Un handshake pe curbă eliptică nu are deloc nevoie de acel fișier, pentru că curba este mulțimea de parametri. Dacă serverul tău negociază doar suite ECDHE, un fișier DH este greutate moartă, nu putere suplimentară.

A doua condiție este autentificarea canalului de control, o funcție separată cu material propriu. Un fișier tls-auth este o cheie statică partajată pe care o au ambele părți, folosită pentru a semna pachetele canalului de control, astfel încât o parte neautentificată să nu poată finaliza nici măcar handshake-ul. Există indiferent dacă folosești DH pe câmp finit sau nu și nu are nimic de-a face cu parametrii grupului.

A treia condiție este secretul și distribuția. Parametrii DH pot fi publicați fără a slăbi sesiunea, pentru că valorile secrete sunt generate pentru fiecare handshake și nu părăsesc niciodată părțile. O cheie statică nu trebuie publicată: sunt aceiași octeți la ambele capete, nu se rotește singură și oricine o deține poate produce semnături valide ale canalului de control. Cele două răspunsuri duc la reguli de tratare complet diferite, și de aceea un fișier poate sta într-un depozit, iar celălalt nu.

Generează materialul corect pentru fiecare rol

Folosește instrumentul care produce formatul așteptat de directivă în loc să convertești între ele. Pentru cheia partajată din OpenVPN 2.6, forma tipizată a generatorului declară scopul explicit.

openvpn --genkey tls-auth ta.key

Acea comandă creează material secret nou; nu repară și nu inspectează o cheie existentă, iar rularea din nou îți dă o cheie diferită pe care celelalte părți nu o au. Copiază fișierul rezultat la părțile care au nevoie de el printr-un canal pe care l-ai folosi pentru orice secret partajat și menține convenția de direcție consecventă: cu tls-auth, o parte folosește key-direction 0, iar cealaltă key-direction 1.

Parametrii DH, când ai nevoie de ei, vin din generarea de parametri și nu dintr-un generator de chei, iar proveniența lor contează chiar dacă ieșirea este publică. Un grup luat dintr-o sursă necunoscută nu devine de încredere pentru că este public; trebuie în continuare să fie un grup asupra căruia părțile tale sunt de acord și unul care nu este slăbit de dimensiunea sau construcția sa.

Ce face dh none și ce nu face

dh none este o directivă reală cu sens îngust: niciun fișier de parametri pentru câmp finit nu va fi încărcat, pentru că handshake-ul folosește Diffie-Hellman pe curbă eliptică. Nu este o prescurtare pentru „sari peste pasul DH” în sensul de a slăbi ceva și cu siguranță nu îi spune OpenVPN să accepte un alt fișier ca substitut.

Din citirea greșită decurg două erori. Prima este să presupui că dh none elimină nevoia de tls-auth, deși cele două controlează lucruri diferite. A doua este să păstrezi o linie dh învechită lângă o configurație doar cu curbă și apoi să te întrebi ce fișier folosește de fapt serverul; dacă directiva este prezentă, fișierul este citit, iar o cale ruptă acolo face pornirea să eșueze dintr-un motiv fără legătură cu schimbul care va fi negociat.

Dacă fișierul greșit a fost deja implementat

Restabilește secretul dorit de la proprietarul profilului și nu atinge verificarea certificatului în timp ce faci asta. Eșecul este o nepotrivire de format, nu un eșec de încredere, iar dezactivarea verificării pentru a ocoli eroarea înlocuiește o problemă de pornire cu una silențioasă.

Apoi separă cele două incidente pe care oamenii tind să le unească. Publicarea unui fișier de parametri DH este aproape inofensivă, pentru că parametrii erau publici prin proiectare. Expunerea cheii tls-auth este un alt eveniment: cheia autentifică pachetele canalului de control pentru fiecare parte care o deține, așa că înlocuirea trebuie coordonată în toată implementarea, nu aplicată pe un singur host.

O verificare de cinci minute hotărăște în care caz ești: citește prima linie a fiecărui fișier, confirmă directiva care îl referențiază și confirmă că distribuția fișierului corespunde cu ceea ce cere materialul. Este o muncă mai mică decât regenerarea unei PKI funcționale, și este ceea ce indicau cele trei condiții tot timpul.