Arquivo DH ou chave tls-auth? Distinguir dois arquivos do OpenVPN

Dois arquivos, duas diretivas e o hábito de nomear ambos pela coisa que configuram. É assim que um dh.pem acaba numa linha tls-auth e o cliente falha com uma mensagem sobre um formato de chave inesperado. A decisão à sua frente não é qual arquivo é mais forte. É qual papel a implantação realmente precisa, e três condições resolvem isso: qual troca de chaves sua pilha TLS vai negociar, se você quer autenticação do canal de controle e se o material precisa permanecer secreto.

Responda a elas em ordem e a pergunta do arquivo se responde sozinha. Pule-as e os nomes das diretivas passam a parecer intercambiáveis, que é exatamente o estado de onde o erro vem.

Leia o rótulo antes do nome do arquivo

A primeira linha do arquivo informa mais que o nome, porque um nome é uma convenção humana e o rótulo é produzido pela ferramenta. Os parâmetros Diffie-Hellman carregam um rótulo PEM BEGIN DH PARAMETERS. Uma chave estática do OpenVPN é uma estrutura completamente diferente, com seu próprio cabeçalho e sua carga hexadecimal.

Renomear não converte nada. Um arquivo de parâmetros chamado ta.key continua sendo parâmetros, e uma chave estática chamada dh.pem continua sendo uma chave estática; o analisador lê o conteúdo e rejeita a discrepância. Verifique antes de editar o perfil:

head -n 1 dh.pem
head -n 1 ta.key

Três condições que decidem qual arquivo você precisa

A primeira condição é a troca. Um handshake Diffie-Hellman de campo finito precisa de um grupo, e a diretiva dh é onde o servidor nomeia os parâmetros para ele. Um handshake de curva elíptica não precisa desse arquivo de modo algum, porque a curva é o conjunto de parâmetros. Se o seu servidor negocia apenas suítes ECDHE, um arquivo DH é peso morto em vez de força extra.

A segunda condição é a autenticação do canal de controle, uma função separada com material próprio. Um arquivo tls-auth é uma chave estática compartilhada que os dois pares têm, usada para assinar pacotes do canal de controle para que um par não autenticado nem consiga concluir o handshake. Existe quer você use DH de campo finito quer não, e não tem nada a ver com os parâmetros do grupo.

A terceira condição é o sigilo e a distribuição. Os parâmetros DH podem ser publicados sem enfraquecer a sessão, porque os valores secretos são gerados por handshake e nunca saem dos pares. Uma chave estática não deve ser publicada: são os mesmos bytes nas duas pontas, não gira sozinha, e quem a tiver pode produzir assinaturas válidas do canal de controle. Essas duas respostas apontam para regras de tratamento completamente diferentes, e por isso um arquivo pode ficar num repositório e o outro não.

Gere o material certo para cada papel

Use a ferramenta que produz o formato que a diretiva espera em vez de converter entre elas. Para a chave compartilhada no OpenVPN 2.6, a forma tipada do gerador declara o propósito explicitamente.

openvpn --genkey tls-auth ta.key

Esse comando cria material secreto novo; não conserta nem inspeciona uma chave existente, e executá-lo de novo dá a você uma chave diferente que os outros pares não têm. Copie o arquivo resultante para os pares que precisam dele por um canal que você usaria para qualquer segredo compartilhado, e mantenha a convenção de direção consistente: com tls-auth, um lado usa key-direction 0 e o outro key-direction 1.

Os parâmetros DH, quando você precisa deles, vêm da geração de parâmetros e não de um gerador de chaves, e sua procedência importa mesmo quando a saída é pública. Um grupo tirado de uma fonte desconhecida não se torna confiável por ser público; ainda precisa ser um grupo com que seus pares concordem e que não seja enfraquecido pelo tamanho ou pela construção.

O que o dh none faz e o que não faz

dh none é uma diretiva real com significado estreito: nenhum arquivo de parâmetros de campo finito será carregado, porque o handshake usa Diffie-Hellman de curva elíptica. Não é uma abreviação de «pular a etapa DH» no sentido de enfraquecer algo, e certamente não diz ao OpenVPN para aceitar outro arquivo como substituto.

Dois erros decorrem de lê-la mal. O primeiro é supor que dh none elimina a necessidade de tls-auth, quando as duas controlam coisas diferentes. O segundo é manter uma linha dh obsoleta ao lado de uma configuração só de curva e depois perguntar qual arquivo o servidor realmente usa; se a diretiva está presente, o arquivo é lido, e um caminho quebrado ali faz a inicialização falhar por um motivo sem relação com a troca que será negociada.

Se o arquivo errado já foi implantado

Restaure o segredo pretendido com o dono do perfil e não mexa na verificação de certificado enquanto faz isso. A falha é uma discrepância de formato, não uma falha de confiança, e desativar a verificação para contornar o erro substitui um problema de inicialização por um silencioso.

Depois separe os dois incidentes que as pessoas tendem a fundir. Publicar um arquivo de parâmetros DH é quase inofensivo, porque os parâmetros eram públicos por projeto. Expor a chave tls-auth é outro acontecimento: a chave autentica pacotes do canal de controle para cada par que a detém, então a substituição precisa ser coordenada em toda a implantação e não aplicada a um único host.

Uma verificação de cinco minutos resolve em qual caso você está: leia a primeira linha de cada arquivo, confirme a diretiva que o referencia e confirme que a distribuição do arquivo corresponde ao que o material exige. É um trabalho menor do que regenerar uma PKI funcional, e é o que as três condições apontavam o tempo todo.