OpenVPN EC contra ED: per què aquests noms no són una escala de força

Poseu ec, ed, ecdh, ecdsa, auth i una llista de xifrats TLS costat a costat en un perfil i el fitxer comença a semblar un dial de força amb sis posicions. Però no ho és. Cada nom respon una pregunta diferent, i dos perfils que difereixen en un d’ells no són necessàriament més forts ni més febles l’un que l’altre. Ordenar els noms segons la feina que fan triga uns cinc minuts i evita la majoria de les males edicions que la gent fa en una configuració que funciona.

L’ordenació de sota comença per la confusió mateixa i després s’obre cap a les parts d’un perfil que decideixen de veritat què protegeix el vostre trànsit. Cada secció pren un malentès alhora i mostra a què va realment lligat el nom.

Dues lletres, dues preguntes diferents

La parella que genera més discussió és EC i ED, i la discussió sol suposar que són respostes rivals a una sola pregunta. Ni tan sols són al mateix eix. EC descriu una família de matemàtiques: la criptografia de corba el·líptica, on la seguretat ve de la dificultat d’un logaritme discret sobre una corba i no en un cos finit gran.

ED descriu una forma de corba dins d’aquesta família. Les corbes Twisted Edwards són una representació triada per la velocitat i per la resistència a diverses errades d’implementació, i Ed25519 és el nom que la gent sol voler dir. La corba no és un competidor de la criptografia de corba el·líptica; és una manera d’escriure una corba el·líptica. Llegir ED com "l’EC més nou i més fort" és el primer gir equivocat, i tot el que ve després sol anar malament en la mateixa direcció.

Signar i intercanviar són feines separades

Un cop resolta la qüestió de la família, els noms restants es reparteixen en dues columnes que mai no se substitueixen l’una a l’altra. Una columna signa, l’altra acorda un secret compartit.

EdDSA i ECDSA signen tots dos, però són esquemes diferents amb formats de clau diferents, així que un certificat emès per a un no es pot fer servir com l’altre. EdDSA està definit per a un conjunt petit de corbes; P-256 no n’és una, i per això un certificat P-256 es verifica amb ECDSA i mai amb Ed25519.

La columna d’intercanvi no té cap equivalent anomenat EdDH. L’acord efímer sobre una clau Curve25519 és X25519, i això és ECDH amb una corba concreta, exactament com amb P-256. Ed25519 vol dir estrictament l’esquema de signatura, encara que el nom es fa servir vagament per a l’intercanvi perquè les dues corbes estan relacionades: la forma Edwards usada per signar i la forma Montgomery usada per a X25519 descriuen el mateix grup subjacent.

Per què un perfil EC no té fitxer dh

Un fitxer dh conté paràmetres generats prèviament per a Diffie-Hellman de cos finit, i aquests paràmetres existeixen perquè un nombre primer gran i un generador han de venir d’algun lloc. Un intercanvi de corba el·líptica no els necessita: la corba anomenada és el conjunt de paràmetres, i tots dos costats ja la coneixen. Aquesta és tota la raó per la qual un perfil EC pot ometre la directiva.

Dues situacions encara produeixen una línia dh en un perfil que d’altra banda sembla modern. La primera és un segon oient o un company més antic que negocia de veritat grups de cos finit. La segona és text sobrant copiat d’una plantilla de l’època RSA i mai no eliminat. Un perfil que anomena una corba per a l’intercanvi i encara carrega un fitxer dh de 2048 bits no és més segur per haver-ho fet; porta un artefacte sense usar.

TLS 1.3 va treure l’intercanvi de claus del nom

Compareu TLS_AES_256_GCM_SHA384 amb TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 i el nom més curt sembla una rebaixa. És un canvi de nom, i el motiu és estructural: TLS 1.3 va treure l’RSA estàtic i l’intercanvi de claus Diffie-Hellman de cos finit, així que un intercanvi efímer de corba el·líptica és l’única opció sense PSK que queda. Anomenar-lo a cada suite repetiria el mateix fet una dotzena de vegades.

El tipus de certificat va desaparèixer del nom per una raó relacionada. A l’1.3 el certificat autentica la signatura de l’apretada de mans, no l’acord de claus, així que ja no selecciona la suite. És també per això que a la configuració hi ha una llista de xifrats separada per a l’1.3: les suites es van renombrar i reorganitzar, no es van debilitar.

Una conseqüència val la pena dir-la clarament. ECDHE és un algorisme d’intercanvi de claus i mai un xifrat. Una suite descrita com a "el·líptica" diu alguna cosa sobre com els dos iguals van arribar a una clau compartida, i res sobre què xifra després la càrrega útil.

auth autentica paquets, no càrregues útils

La directiva auth selecciona el resum HMAC que autentica els paquets, i el seu valor per defecte històric és SHA1. Amb un xifrat de dades que no és AEAD, OpenVPN calcula el resum sobre el text xifrat i l’afegeix, un arranjament xifra-i-després-MAC que és el que fa impràctic manipular el farciment.

El mite aquí és que pujar auth a SHA512 enforteix el túnel. No augmenta la força del xifratge, i si el xifrat de dades negociat és un mode AEAD com AES-256-GCM, el resum no s’aplica gens als paquets de dades. L’etiqueta GCM ja els autentica, i el valor auth queda per a l’HMAC del canal de control i per a qualsevol xifrat que no sigui AEAD i encara s’usi.

Així que la directiva importa, però importa en un lloc més estret del que suggereix la seva posició al fitxer. Comprovar quin xifrat s’ha negociat de veritat us diu si s’aplica o no.

Llegiu el perfil per columna, no per rang

Tres preguntes separen les capes netament, i cadascuna la respon una part diferent de la sessió negociada. Quin xifrat protegeix la càrrega útil? Quina etiqueta o resum respon per cada paquet, i el xifrat en ús encara en necessita una? Quin certificat va tancar l’apretada de mans, i el canal de control està protegit a més per tls-auth o tls-crypt?

Res de l’etiqueta EC o ED no resol cap d’aquestes tres, i un nom de suite tot sol tampoc no en resol cap. El resultat negociat és l’única evidència, així que llegiu-lo en lloc d’inferir la força del vocabulari:

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

La primera ordre us diu quin esquema de signatura fa servir realment el vostre certificat, que és l’única manera fiable de saber si feu anar ECDSA o Ed25519. La segona mostra la línia del canal de control que el client va registrar per a la sessió, incloent-hi la versió de TLS i la suite amb què es va quedar. Si una edició del perfil no es pot justificar amb una d’aquestes dues sortides, probablement és un canvi de nom i no de propietat.