OpenVPN EC vs ED: de ce aceste nume nu sunt o scară a puterii

Puneți ec, ed, ecdh, ecdsa, auth și o listă de cifruri TLS unul lângă altul într-un singur profil, iar fișierul începe să arate ca un buton de putere cu șase poziții. Dar nu este. Fiecare nume răspunde la o altă întrebare, iar două profiluri care diferă la unul dintre ele nu sunt neapărat mai puternice sau mai slabe unul decât celălalt. Sortarea numelor după munca pe care o fac durează aproximativ cinci minute și împiedică majoritatea modificărilor rele pe care oamenii le fac într-o configurație care funcționează.

Sortarea de mai jos pornește de la confuzia însăși și apoi merge spre exterior, către părțile unui profil care decid cu adevărat ce vă protejează traficul. Fiecare secțiune ia pe rând o citire greșită și arată de ce este numele legat în realitate.

Două litere, două întrebări diferite

Perechea care stârnește cele mai multe dispute este EC și ED, iar disputa presupune de obicei că sunt răspunsuri rivale la o singură întrebare. Nu sunt nici măcar pe aceeași axă. EC descrie o familie de matematică: criptografia pe curbă eliptică, unde securitatea vine din dificultatea unui logaritm discret pe o curbă și nu într-un corp finit mare.

ED descrie o formă de curbă în interiorul acelei familii. Curbele Twisted Edwards sunt o reprezentare aleasă pentru viteză și pentru rezistența la mai multe erori de implementare, iar Ed25519 este numele la care oamenii se referă de obicei. Curba nu este un concurent al criptografiei pe curbă eliptică; este o modalitate de a scrie o curbă eliptică. Citirea ED ca "EC-ul mai nou și mai puternic" este prima cotitură greșită, iar tot ce urmează tinde să fie greșit în aceeași direcție.

Semnarea și schimbul sunt sarcini separate

Odată ce întrebarea familiei este lămurită, numele rămase se împart în două coloane care nu se înlocuiesc niciodată. O coloană semnează, cealaltă se învoiește asupra unui secret comun.

EdDSA și ECDSA semnează amândouă, dar sunt scheme diferite cu formate de cheie diferite, așa că un certificat emis pentru una nu poate fi folosit ca cealaltă. EdDSA este definită pentru un set mic de curbe; P-256 nu este una dintre ele, motiv pentru care un certificat P-256 se verifică cu ECDSA și niciodată cu Ed25519.

Coloana de schimb nu are un echivalent numit EdDH. Acordul efemer pe o cheie Curve25519 este X25519, iar aceasta este ECDH cu o anumită curbă, exact ca în cazul P-256. Ed25519 înseamnă strict schema de semnătură, deși numele este folosit lejer pentru schimb pentru că cele două curbe sunt înrudite: forma Edwards folosită pentru semnare și forma Montgomery folosită pentru X25519 descriu același grup de bază.

De ce un profil EC nu are fișier dh

Un fișier dh conține parametri generați în avans pentru Diffie-Hellman în corp finit, iar acești parametri există pentru că un număr prim mare și un generator trebuie să vină de undeva. Un schimb pe curbă eliptică nu are nevoie de ei: curba numită este setul de parametri, iar ambele părți îl cunosc deja. Acesta este tot motivul pentru care un profil EC poate omite directiva.

Două situații produc în continuare o linie dh într-un profil care altfel pare modern. Prima este un al doilea ascultător sau un partener mai vechi care chiar negociază grupuri de corp finit. A doua este text rămas copiat dintr-un șablon din epoca RSA și niciodată eliminat. Un profil care numește o curbă pentru schimb și încarcă în continuare un fișier dh de 2048 de biți nu este mai sigur pentru că a făcut asta; duce cu el un artefact nefolosit.

TLS 1.3 a scos schimbul de chei din nume

Comparați TLS_AES_256_GCM_SHA384 cu TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 și numele mai scurt pare o retrogradare. Este o redenumire, iar motivul este structural: TLS 1.3 a eliminat RSA static și schimbul de chei Diffie-Hellman în corp finit, așa că un schimb efemer pe curbă eliptică este singura opțiune fără PSK care a rămas. Să-l numești în fiecare suită ar repeta același fapt o duzină de ori.

Tipul de certificat a dispărut din nume dintr-un motiv înrudit. În 1.3 certificatul autentifică semnătura strângerii de mână, nu acordul asupra cheii, așa că nu mai selectează suita. De aceea există în configurație o listă de cifruri separată pentru 1.3: suitele au fost redenumite și reorganizate, nu slăbite.

O consecință merită spusă direct. ECDHE este un algoritm de schimb de chei și niciodată un cifru. O suită descrisă drept "eliptică" spune ceva despre felul în care cele două părți au ajuns la o cheie comună și nimic despre ce anume cifrează apoi încărcătura utilă.

auth autentifică pachete, nu încărcături utile

Directiva auth selectează rezumatul HMAC care autentifică pachetele, iar valoarea ei implicită istorică este SHA1. Cu un cifru de date care nu este AEAD, OpenVPN calculează rezumatul peste textul cifrat și îl adaugă, o aranjare cifrează-și-apoi-MAC care face manipularea umpluturii nepractică.

Mitul de aici este că ridicarea auth la SHA512 întărește tunelul. Nu crește puterea criptării, iar dacă cifrul de date negociat este un mod AEAD precum AES-256-GCM, rezumatul nu se aplică deloc pachetelor de date. Eticheta GCM le autentifică deja, iar valoarea auth rămâne pentru HMAC-ul canalului de control și pentru orice cifru fără AEAD încă folosit.

Deci directiva contează, dar contează într-un loc mai îngust decât sugerează poziția ei în fișier. Verificarea cifrului care a fost negociat efectiv vă spune dacă se aplică sau nu.

Citiți profilul pe coloană, nu pe rang

Trei întrebări separă curat straturile, iar la fiecare răspunde o altă parte a sesiunii negociate. Care cifru protejează încărcătura utilă? Care etichetă sau rezumat garantează pentru fiecare pachet și are cifrul folosit măcar nevoie de așa ceva? Al cui certificat a închis strângerea de mână și este canalul de control protejat în plus de tls-auth sau tls-crypt?

Nimic din eticheta EC sau ED nu decide vreuna dintre aceste trei, iar un nume de suită singur nu decide niciuna dintre ele. Rezultatul negociat este singura dovadă, așa că citiți-l în loc să deduceți puterea din vocabular:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Prima comandă vă spune ce schemă de semnătură folosește de fapt certificatul dumneavoastră, iar acesta este singurul mod sigur de a ști dacă rulați ECDSA sau Ed25519. A doua arată linia canalului de control pe care clientul a înregistrat-o pentru sesiune, inclusiv versiunea TLS și suita la care s-a oprit. Dacă o modificare a profilului nu poate fi justificată de una dintre aceste două ieșiri, este probabil o schimbare de nume și nu de proprietate.