OpenVPN EC vs ED: por que estes nomes não são uma escada de força

Coloque ec, ed, ecdh, ecdsa, auth e uma lista de cifras TLS lado a lado num único perfil, e o ficheiro começa a parecer um botão de força com seis posições. Mas não é. Cada nome responde a uma pergunta diferente, e dois perfis que diferem num deles não são necessariamente mais fortes ou mais fracos um que o outro. Ordenar os nomes pelo trabalho que fazem leva cerca de cinco minutos e evita a maioria das más edições que as pessoas fazem numa configuração que funciona.

A ordenação abaixo parte da própria confusão e depois avança para fora, para as partes de um perfil que realmente decidem o que protege o seu tráfego. Cada secção pega, por sua vez, numa leitura errada e mostra a que o nome está realmente ligado.

Duas letras, duas perguntas diferentes

O par que gera mais discussão é EC e ED, e a discussão costuma assumir que são respostas rivais a uma única pergunta. Nem sequer estão no mesmo eixo. EC descreve uma família de matemática: a criptografia de curva elíptica, em que a segurança vem da dificuldade de um logaritmo discreto numa curva e não num corpo finito grande.

ED descreve uma forma de curva dentro dessa família. As curvas Twisted Edwards são uma representação escolhida pela velocidade e pela resistência a vários erros de implementação, e Ed25519 é o nome que as pessoas costumam querer dizer. A curva não é um concorrente da criptografia de curva elíptica; é uma forma de escrever uma curva elíptica. Ler ED como "o EC mais recente e mais forte" é a primeira curva errada, e tudo o que vem depois tende a estar errado na mesma direção.

Assinar e trocar são tarefas separadas

Uma vez resolvida a questão da família, os nomes restantes dividem-se em duas colunas que nunca se substituem. Uma coluna assina, a outra acorda um segredo partilhado.

EdDSA e ECDSA assinam ambos, mas são esquemas diferentes com formatos de chave diferentes, por isso um certificado emitido para um não é utilizável como o outro. EdDSA está definido para um pequeno conjunto de curvas; P-256 não é uma delas, e é por isso que um certificado P-256 é verificado com ECDSA e nunca com Ed25519.

A coluna de troca não tem equivalente chamado EdDH. O acordo efémero sobre uma chave Curve25519 é X25519, e isso é ECDH com uma curva concreta, exatamente como com P-256. Ed25519 significa estritamente o esquema de assinatura, embora o nome seja usado de forma solta para a troca porque as duas curvas estão relacionadas: a forma Edwards usada para assinar e a forma Montgomery usada para X25519 descrevem o mesmo grupo subjacente.

Por que um perfil EC não tem ficheiro dh

Um ficheiro dh contém parâmetros gerados de antemão para Diffie-Hellman de corpo finito, e esses parâmetros existem porque um número primo grande e um gerador têm de vir de algum lado. Uma troca de curva elíptica não precisa deles: a curva nomeada é o conjunto de parâmetros, e ambos os lados já a conhecem. É essa toda a razão pela qual um perfil EC pode omitir a diretiva.

Duas situações ainda produzem uma linha dh num perfil que, de resto, parece moderno. A primeira é um segundo ouvinte ou um par mais antigo que negoceia mesmo grupos de corpo finito. A segunda é texto sobrante copiado de um modelo da era RSA e nunca removido. Um perfil que nomeia uma curva para a troca e ainda carrega um ficheiro dh de 2048 bits não é mais seguro por o ter feito; carrega um artefacto sem uso.

TLS 1.3 retirou a troca de chaves do nome

Compare TLS_AES_256_GCM_SHA384 com TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 e o nome mais curto parece uma degradação. É uma mudança de nome, e a razão é estrutural: TLS 1.3 removeu o RSA estático e a troca de chaves Diffie-Hellman de corpo finito, por isso uma troca efémera de curva elíptica é a única opção sem PSK que resta. Nomeá-la em cada suite repetiria o mesmo facto uma dúzia de vezes.

O tipo de certificado desapareceu do nome por uma razão relacionada. Em 1.3 o certificado autentica a assinatura do aperto de mão, não o acordo de chaves, por isso já não seleciona a suite. É também por isso que existe uma lista de cifras separada para 1.3 na configuração: as suites foram renomeadas e reorganizadas, não enfraquecidas.

Uma consequência merece ser dita sem rodeios. ECDHE é um algoritmo de troca de chaves e nunca uma cifra. Uma suite descrita como "elíptica" diz algo sobre como os dois pares chegaram a uma chave partilhada, e nada sobre o que cifra depois a carga útil.

auth autentica pacotes, não cargas úteis

A diretiva auth seleciona o resumo HMAC que autentica os pacotes, e o seu valor predefinido histórico é SHA1. Com uma cifra de dados que não é AEAD, o OpenVPN calcula o resumo sobre o texto cifrado e acrescenta-o, um arranjo cifrar-e-depois-MAC que é o que torna impraticável manipular o preenchimento.

O mito aqui é que subir auth para SHA512 endurece o túnel. Não aumenta a força da cifragem, e se a cifra de dados negociada for um modo AEAD como AES-256-GCM, o resumo não é aplicado de todo aos pacotes de dados. A etiqueta GCM já os autentica, e o valor auth fica para o HMAC do canal de controlo e para qualquer cifra que não seja AEAD e ainda esteja em uso.

Por isso a diretiva importa, mas importa num lugar mais estreito do que a sua posição no ficheiro sugere. Verificar que cifra foi realmente negociada diz-lhe se ela se aplica ou não.

Leia o perfil por coluna, não por escalão

Três perguntas separam as camadas com clareza, e a cada uma responde uma parte diferente da sessão negociada. Que cifra protege a carga útil? Que etiqueta ou resumo garante cada pacote, e a cifra em uso precisa mesmo de uma? Que certificado fechou o aperto de mão, e o canal de controlo está ainda protegido por tls-auth ou tls-crypt?

Nada na etiqueta EC ou ED resolve qualquer uma dessas três, e um nome de suite por si só também não resolve nenhuma. O resultado negociado é a única prova, por isso leia-o em vez de inferir a força do vocabulário:

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 diz-lhe que esquema de assinatura o seu certificado usa realmente, e é a única forma fiável de saber se está a correr ECDSA ou Ed25519. O segundo mostra a linha do canal de controlo que o cliente registou para a sessão, incluindo a versão de TLS e a suite com que ficou. Se uma edição do perfil não puder ser justificada por uma dessas duas saídas, é provavelmente uma mudança de nome e não de propriedade.