OpenVPN EC fronte a ED: por que estes nomes non son unha escala de forza

Poña ec, ed, ecdh, ecdsa, auth e unha lista de cifrados TLS un a carón do outro nun mesmo perfil e o ficheiro comeza a parecer un dial de forza con seis posicións. Pero non o é. Cada nome responde a unha pregunta distinta, e dous perfís que difiren nun deles non son necesariamente máis fortes ou máis débiles un ca o outro. Ordenar os nomes segundo o traballo que fan leva uns cinco minutos e evita a maioría das malas edicións que a xente fai nunha configuración que funciona.

A orde que segue parte da propia confusión e despois avanza cara a fóra, cara ás partes dun perfil que de verdade deciden que protexe o seu tráfico. Cada sección toma pola súa vez unha mala lectura e mostra a que está realmente ligado o nome.

Dúas letras, dúas preguntas distintas

O par que xera máis discusión é EC e ED, e a discusión adoita supor que son respostas rivais a unha soa pregunta. Nin sequera están no mesmo eixe. EC describe unha familia de matemáticas: a criptografía de curva elíptica, onde a seguridade vén da dificultade dun logaritmo discreto sobre unha curva e non nun corpo finito grande.

ED describe unha forma de curva dentro desa familia. As curvas Twisted Edwards son unha representación escollida pola velocidade e pola resistencia a varios erros de implementación, e Ed25519 é o nome que a xente adoita querer dicir. A curva non é un competidor da criptografía de curva elíptica; é unha forma de escribir unha curva elíptica. Ler ED como "o EC máis novo e máis forte" é o primeiro xiro equivocado, e todo o que vén despois adoita estar mal na mesma dirección.

Asinar e intercambiar son tarefas separadas

Unha vez resolta a cuestión da familia, os nomes restantes repártense en dúas columnas que nunca se substitúen entre si. Unha columna asina, a outra acorda un segredo compartido.

EdDSA e ECDSA asinan ambos, pero son esquemas distintos con formatos de clave distintos, así que un certificado emitido para un non serve como o outro. EdDSA está definido para un conxunto pequeno de curvas; P-256 non é unha delas, e por iso un certificado P-256 verifícase con ECDSA e nunca con Ed25519.

A columna de intercambio non ten ningún equivalente chamado EdDH. O acordo efémero sobre unha clave Curve25519 é X25519, e iso é ECDH cunha curva concreta, exactamente igual que con P-256. Ed25519 significa estritamente o esquema de sinatura, aínda que o nome se usa de forma laxa para o intercambio porque as dúas curvas están relacionadas: a forma Edwards usada para asinar e a forma Montgomery usada para X25519 describen o mesmo grupo subxacente.

Por que un perfil EC non ten ficheiro dh

Un ficheiro dh contén parámetros xerados de antemán para Diffie-Hellman de corpo finito, e eses parámetros existen porque un número primo grande e un xerador teñen que vir dalgún sitio. Un intercambio de curva elíptica non os necesita: a curva nomeada é o conxunto de parámetros, e ambos os dous lados xa o coñecen. Ese é todo o motivo polo que un perfil EC pode omitir a directiva.

Dúas situacións seguen producindo unha liña dh nun perfil que polo demais parece moderno. A primeira é un segundo escoitante ou un par máis antigo que negocia de verdade grupos de corpo finito. A segunda é texto sobrante copiado dun modelo da época RSA e nunca eliminado. Un perfil que nomea unha curva para o intercambio e aínda así carga un ficheiro dh de 2048 bits non é máis seguro por facelo; leva un artefacto sen usar.

TLS 1.3 quitou o intercambio de claves do nome

Compare TLS_AES_256_GCM_SHA384 con TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 e o nome máis curto parece unha degradación. É un cambio de nome, e a razón é estrutural: TLS 1.3 eliminou o RSA estático e o intercambio de claves Diffie-Hellman de corpo finito, así que un intercambio efémero de curva elíptica é a única opción sen PSK que queda. Nomealo en cada suite repetiría o mesmo feito unha ducia de veces.

O tipo de certificado desapareceu do nome por unha razón relacionada. En 1.3 o certificado autentica a sinatura do apretón de mans, non o acordo de claves, así que xa non selecciona a suite. É tamén por iso polo que existe unha lista de cifrados aparte para 1.3 na configuración: as suites renombráronse e reorganizáronse, non se debilitaron.

Unha consecuencia merece dicirse sen rodeos. ECDHE é un algoritmo de intercambio de claves e nunca un cifrado. Unha suite descrita como "elíptica" di algo sobre como chegaron os dous pares a unha clave compartida, e nada sobre que cifra despois a carga útil.

auth autentica paquetes, non cargas útiles

A directiva auth selecciona o resumo HMAC que autentica os paquetes, e o seu valor predeterminado histórico é SHA1. Cun cifrado de datos que non é AEAD, OpenVPN calcula o resumo sobre o texto cifrado e engádeo, un arranxo cifrar-e-despois-MAC que é o que fai impracticable manipular o recheo.

O mito aquí é que subir auth a SHA512 endurece o túnel. Non aumenta a forza do cifrado, e se o cifrado de datos negociado é un modo AEAD como AES-256-GCM, o resumo non se aplica en absoluto aos paquetes de datos. A etiqueta GCM xa os autentica, e o valor auth queda para o HMAC da canle de control e para calquera cifrado que non sexa AEAD e siga en uso.

Así que a directiva importa, pero importa nun lugar máis estreito do que suxire a súa posición no ficheiro. Comprobar que cifrado se negociou realmente dálle a resposta de se se aplica ou non.

Lea o perfil por columna, non por rango

Tres preguntas separan as capas con claridade, e cada unha respóndea unha parte distinta da sesión negociada. Que cifrado protexe a carga útil? Que etiqueta ou resumo responde por cada paquete, e o cifrado en uso necesita sequera unha? Que certificado pechou o apretón de mans, e a canle de control está protexida ademais por tls-auth ou tls-crypt?

Nada na etiqueta EC ou ED resolve ningunha desas tres, e un nome de suite por si só tampouco resolve ningunha. O resultado negociado é a única proba, así que lelo en vez de inferir a forza do vocabulario:

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

O primeiro comando dille que esquema de sinatura usa realmente o seu certificado, que é a única forma fiable de saber se está a executar ECDSA ou Ed25519. O segundo mostra a liña da canle de control que o cliente rexistrou para a sesión, incluída a versión de TLS e a suite coa que quedou. Se unha edición do perfil non se pode xustificar cunha desas dúas saídas, probablemente sexa un cambio de nome e non de propiedade.