Poate un certificat RSA să funcționeze cu dh none în OpenVPN?

Iată o configurație de server care spune dh none lângă un certificat care spune RSA, plus suspiciunea enervantă că unul dintre ele trebuie să fie greșit. Nimic nu este greșit. Certificatul semnează și autentifică; schimbul de chei stabilește un secret comun. Sunt două sarcini diferite în același handshake, iar TLS permite unui certificat RSA să autentifice un handshake care folosește un acord efemer pe curbă eliptică.

Confuzia vine de obicei cu un ghid de migrare. Acesta spune să înlocuiți fișierul de parametri DH cu dh none, cititorul observă că certificatul nu este un certificat de curbă eliptică, iar cele două fapte sunt tratate ca o contradicție.

De ce cele două setări par legate

Configurația mai veche a OpenVPN cerea un fișier de parametri DH pentru că Diffie-Hellman în corp finit are nevoie de parametri de domeniu asupra cărora ambele părți cad de acord. Directiva dh indica spre acel fișier. Când o implementare trece la ECDH, parametrii provin dintr-o curbă numită, iar fișierul nu mai este necesar, ceea ce exprimă dh none.

Certificatele sunt o axă separată. Ele poartă o cheie publică și o semnătură care dovedesc identitatea serverului, iar cheia poate fi RSA sau curbă eliptică indiferent de modul în care se convine cheia sesiunii. Un handshake care folosește ECDHE pentru acordul cheii și RSA pentru autentificare este obișnuit și implementat pe scară largă.

Denumirea agravează suprapunerea. Curba eliptică apare atât în numele suitei ECDHE, cât și în ECDSA, așa că este ușor să presupunem că orice conexiune care menționează o curbă trebuie să includă un certificat de curbă. Nu este cazul.

Cum se citește corect numele unei suite TLS 1.2

Luați ECDHE-RSA-AES256-GCM-SHA384. Primul token este familia de schimb de chei: Diffie-Hellman efemer pe curbă eliptică. Al doilea este familia de autentificare: RSA. Restul descrie protecția înregistrărilor și hash-ul folosit în handshake.

O suită ECDHE-ECDSA folosește aceeași familie de schimb de chei cu o metodă de autentificare diferită, deci are nevoie de un certificat de curbă eliptică. O suită DHE-RSA folosește Diffie-Hellman efemer în corp finit cu autentificare RSA, iar aceea chiar are nevoie de parametri DH.

Citiți numele suitei de la stânga la dreapta și atribuiți fiecărei părți sarcina ei. Odată separate tokenurile, întrebarea se schimbă de la «certificatul meu se potrivește cu dh none» la «serverul meu permite o suită al cărei schimb de chei nu are nevoie de un fișier DH».

Ce dezactivează de fapt dh none

dh none îi spune serverului să nu încarce un fișier de parametri DH în corp finit. Nu dezactivează autentificarea, validarea certificatelor sau TLS însuși. Cere însă ca schimbul de chei negociat să nu aibă nevoie de acești parametri, ceea ce în practică înseamnă o suită ECDHE sau un handshake TLS 1.3.

Din această cerință vine defecțiunea. Dacă politica de cifruri TLS a serverului este limitată la suite DHE, sau un client oferă doar acestea, eliminarea fișierului de parametri nu lasă nicio metodă de schimb de chei utilizabilă și handshake-ul eșuează. Eroarea apare de obicei în timpul handshake-ului canalului de control, înainte de orice autentificare a utilizatorului. Citiți lista de cifruri înainte de a da vina pe fișierul lipsă.

Pe partea de curbă eliptică, curba este aleasă de configurația TLS a serverului, iar OpenVPN oferă o opțiune pentru a o alege pe ramurile mai vechi. TLS 1.3 gestionează negocierea grupului în interiorul protocolului și nu consultă deloc fișierul DH.

dh none nu este în sine o scădere de securitate. Puterea schimbului depinde atunci de curba și suita negociate efectiv, motiv pentru care pasul următor este să priviți ce au ales peer-ii, nu fișierul absent.

Confirmarea negocierii înainte de editare

Creșteți gradul de detaliu al serverului și al clientului și citiți linia canalului de control pe care OpenVPN o tipărește după o conexiune. Aceasta numește versiunea TLS și cifrul negociat și raportează tipul de cheie al certificatului peer-ului. Acea singură linie răspunde la întrebarea pe care fișierul de configurare doar o sugerează.

Dacă arată TLS 1.2 cu o suită ECDHE-RSA și un certificat RSA, combinația este exact ceea ce așteaptă dh none, și nu este nimic de reparat. Dacă arată o suită DHE sau un eșec de handshake fără cifru comun, remedierea este în politica de cifruri sau în capacitatea clientului, nu în certificat.

Testați cel mai vechi client pe care intenționați să îl suportați, deoarece un client actual poate negocia TLS 1.3 în timp ce unul mai vechi este limitat la suite TLS 1.2. Dacă cel mai vechi client nu are suprapunere, fie lărgiți suitele permise, fie actualizați acel endpoint.

Nu dezactivați verificarea certificatelor pentru a trece de un eșec de handshake. Eșecul vă spune că părțile nu au putut conveni asupra unui schimb de chei, iar dezactivarea verificării elimină garanția identității fără a rezolva acordul.

Listă de verificare: certificatul este RSA, o suită ECDHE este permisă, jurnalul arată acea suită și cel mai vechi client suportat o negociază? Dacă toate patru sunt da, dh none își face treaba.