Um certificado RSA pode funcionar com dh none no OpenVPN?

Aqui está uma configuração de servidor que diz dh none ao lado de um certificado que diz RSA, mais a suspeita incômoda de que um dos dois deve estar errado. Nada está errado. O certificado assina e autentica; a troca de chaves estabelece um segredo compartilhado. São duas tarefas diferentes no mesmo handshake, e o TLS permite que um certificado RSA autentique um handshake que usa acordo efêmero sobre curva elíptica.

A confusão costuma chegar com um guia de migração. Ele diz para substituir o arquivo de parâmetros DH por dh none, o leitor percebe que o certificado não é um certificado de curva elíptica, e os dois fatos são tratados como contradição.

Por que as duas configurações parecem relacionadas

A configuração mais antiga do OpenVPN exigia um arquivo de parâmetros DH porque Diffie-Hellman de campo finito precisa de parâmetros de domínio com os quais ambos os lados concordam. A diretiva dh apontava para esse arquivo. Quando uma implantação passa para ECDH, os parâmetros vêm de uma curva nomeada, e o arquivo não é mais necessário, o que dh none expressa.

Certificados são um eixo separado. Eles carregam uma chave pública e uma assinatura que provam a identidade do servidor, e essa chave pode ser RSA ou de curva elíptica independentemente de como a chave de sessão é acordada. Um handshake que usa ECDHE para o acordo de chave e RSA para autenticação é comum e amplamente implantado.

A nomenclatura piora a sobreposição. A curva elíptica aparece nos nomes de suíte ECDHE e ECDSA, então é fácil supor que qualquer conexão que mencione uma curva deva incluir um certificado de curva. Não é o caso.

Como ler corretamente um nome de suíte TLS 1.2

Tome ECDHE-RSA-AES256-GCM-SHA384. O primeiro token é a família de troca de chaves: Diffie-Hellman efêmero sobre curva elíptica. O segundo é a família de autenticação: RSA. O restante descreve a proteção de registros e o hash usado no handshake.

Uma suíte ECDHE-ECDSA usa a mesma família de troca de chaves com um método de autenticação diferente, então precisa de um certificado de curva elíptica. Uma suíte DHE-RSA usa Diffie-Hellman efêmero de campo finito com autenticação RSA, e essa realmente precisa de parâmetros DH.

Leia um nome de suíte da esquerda para a direita e atribua cada parte à sua tarefa. Uma vez separados os tokens, a pergunta muda de «meu certificado combina com dh none» para «meu servidor permite uma suíte cuja troca de chaves não precisa de um arquivo DH».

O que dh none realmente desativa

dh none diz ao servidor para não carregar um arquivo de parâmetros DH de campo finito. Ele não desativa autenticação, validação de certificados nem o próprio TLS. O que ele exige é que a troca de chaves negociada seja uma que não precise desses parâmetros, o que na prática significa uma suíte ECDHE ou um handshake TLS 1.3.

É desse requisito que vem a quebra. Se a política de cifras TLS do servidor estiver restrita a suítes DHE, ou se um cliente oferecer apenas essas, remover o arquivo de parâmetros não deixa nenhum método de troca de chaves utilizável e o handshake falha. O erro geralmente aparece durante o handshake do canal de controle, antes de qualquer autenticação de usuário. Leia a lista de cifras antes de culpar o arquivo ausente.

Do lado da curva elíptica, a curva é escolhida pela configuração TLS do servidor, e o OpenVPN oferece uma opção para escolhê-la em ramos mais antigos. O TLS 1.3 trata a negociação do grupo dentro do protocolo e não consulta o arquivo DH de forma alguma.

dh none não é uma redução de segurança por si só. A força da troca depende então da curva e da suíte realmente negociadas, por isso o próximo passo é olhar o que os pares escolheram e não o arquivo ausente.

Confirmar a negociação antes de editar

Aumente a verbosidade do servidor e do cliente e leia a linha do canal de controle que o OpenVPN imprime após uma conexão. Ela nomeia a versão do TLS e a cifra negociada, e informa o tipo de chave do certificado do par. Essa única linha responde à pergunta que o arquivo de configuração apenas insinua.

Se mostrar TLS 1.2 com uma suíte ECDHE-RSA e um certificado RSA, a combinação é exatamente o que dh none espera, e não há nada a reparar. Se mostrar uma suíte DHE ou uma falha de handshake sem cifra comum, a correção está na política de cifras ou na capacidade do cliente, não no certificado.

Teste o cliente mais antigo que pretende suportar, porque um cliente atual pode negociar TLS 1.3 enquanto um mais antigo está limitado a suítes TLS 1.2. Se o cliente mais antigo não tiver sobreposição, amplie as suítes permitidas ou atualize esse endpoint.

Não desative a verificação de certificados para superar uma falha de handshake. A falha está dizendo que os pares não conseguiram concordar sobre uma troca de chaves, e desativar a verificação remove a garantia de identidade sem resolver o acordo.

Lista de verificação: o certificado é RSA, uma suíte ECDHE é permitida, o log mostra essa suíte e o cliente suportado mais antigo também a negocia? Se as quatro respostas forem sim, dh none está fazendo seu trabalho.