SECLEVEL=0 trata o sintoma, não o certificado

Uma conexão OpenVPN falha, alguém encontra uma correção de uma linha que adiciona SECLEVEL=0, e o túnel sobe. O que mudou não foi o certificado nem o conjunto de cifras; um limiar de aceitação em toda a biblioteca se deslocou, e tudo o que o processo faz depois herda a nova fronteira. Vale a pena entender isso antes que a mesma linha seja copiada para cada perfil do parque.

Determine qual biblioteca e qual política estão em vigor

SECLEVEL é um conceito do OpenSSL, então a primeira pergunta é se a sua compilação usa OpenSSL. O OpenVPN pode ser ligado a mais de uma biblioteca criptográfica, e um ajuste que se aplica a uma delas não faz sentido para as outras. Pergunte ao binário com o que foi construído e depois pergunte à biblioteca que versão e configuração ela carregou:

openvpn --version | head -3
openssl version -a

Leia a saída da versão com atenção, porque as distribuições corrigem os valores padrão. Algumas trazem uma configuração de sistema que eleva o nível mínimo acima do padrão do upstream, e por isso o mesmo perfil se comporta de forma diferente em duas máquinas com pacotes OpenVPN idênticos. A política efetiva é a que o processo em execução carregou, não a do manual do upstream.

Depois separe as duas camadas que as pessoas confundem. O OpenVPN tem os seus próprios controles TLS, incluindo um ajuste de perfil de certificado e listas explícitas de cifras, e estes ficam acima de tudo o que a biblioteca impõe. Baixar o nível da biblioteca não muda quais cifras a sua configuração do OpenVPN lista, e restringir a lista do OpenVPN não eleva o limiar da biblioteca. Saber qual camada o rejeitou é o que impede que a correção continue a ser um palpite.

Separe as três coisas que podem ser rejeitadas

O primeiro candidato é material de identidade: um certificado cuja chave é demasiado pequena ou cujo algoritmo de assinatura a política já não aceita. O segundo é um parâmetro de troca de chaves, como um grupo que a política considera demasiado fraco. O terceiro é um conjunto de cifras que a política exclui. Os três podem produzir uma falha de handshake, e só o texto do erro e a etapa de negociação os distingue.

Nenhum desses três é a cifra do canal de dados. O OpenVPN negoceia a cifragem do túnel separadamente do handshake TLS, por isso uma conexão que tem sucesso após uma mudança de nível de segurança não diz nada sobre qual cifra protege os seus dados. Se a pergunta que está realmente a fazer é sobre a confidencialidade dos dados, está a olhar para o botão errado.

Baixar o nível amplia a aceitação das três entradas ao mesmo tempo. É essa a parte que as pessoas perdem: a correção que admite um certificado antigo também admite um grupo fraco e um conjunto que talvez não pretendesse permitir. Um único erro motivou a mudança, e a mudança é mais ampla do que o erro. Essa assimetria é a razão pela qual uma exceção delimitada é melhor do que um padrão para todo o parque.

Mude a entrada, não o limiar

Guarde o erro exato antes de tocar na configuração, incluindo a etapa que o reportou e o objeto que ele nomeou. Um problema de certificado resolve-se substituindo o certificado por algo que a política atual aceite, o que normalmente significa reemitilo na autoridade em vez de reinstalar o mesmo ficheiro.

Se a entrada rejeitada pertence a um par que não controla, a conversa é com o proprietário desse par sobre material de substituição suportado. Baixar o seu próprio limiar para acomodar um sistema que ninguém mantém transfere o custo deles para todos os que se ligam depois.

Onde o servidor aplica a política, verifique se uma configuração ao nível do OpenVPN é a causa real antes de culpar a biblioteca. Um perfil de certificado que exige uma classe mais estrita do que o certificado implementado pode satisfazer falhará independentemente do nível de segurança, e remover esse perfil é uma mudança mais estreita do que desativar as verificações da biblioteca.

Se tiver de o baixar, delimite-o e documente-o

Por vezes uma exceção de compatibilidade aprovada é a resposta certa, sobretudo para um par antigo com um plano de retirada datado. Delimite-a ao serviço que precisa dela em vez de a todo o host: um ficheiro de configuração por serviço ou uma configuração OpenSSL dedicada tem um raio de impacto menor do que uma exportação no perfil global.

Anote quatro coisas com a exceção: a configuração exata, o proprietário que a aprovou, os clientes afetados e a condição em que é removida. Uma exceção sem condição de retirada é um enfraquecimento permanente com uma justificação temporária anexada.

A reversão deve ser um único passo que já testou. Guarde a configuração anterior, aplique a mudança, confirme que o serviço arranca e saiba exatamente que ficheiro restaurar se a próxima conexão se comportar de forma diferente do esperado.

Verifique a identidade e a proteção depois

Uma conexão bem-sucedida apenas prova que as condições revistas a admitiram. Confirme que a verificação do nome do host e do par continua a fazer o seu trabalho, que o certificado em uso é o que pretendia implementar e que o canal de dados negociado corresponde à política que pensa ter.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

A referência dos níveis de segurança do OpenSSL é explícita em dizer que a estrutura aplica limites a chaves, assinaturas, grupos e conjuntos em conjunto, e que o nível zero permite tudo o que a função de retorno verifica. Esse é o alcance do que mudou, e é a frase a citar quando alguém pergunta se a correção era estreita.

A passagem que sobrevive a uma auditoria diz que política rejeitou que entrada, o que foi mudado e o que continua aceite como resultado. «Funciona com SECLEVEL=0» é uma observação sobre uma conexão, não uma avaliação de segurança da implementação.