Um par antigo força TLS 1.0: limite a exceção, não o host

Surge um dispositivo antigo, não consegue conectar, e o reparo que parece mais rápido é enfraquecer o host inteiro até a conexão dar certo. Essa troca é invisível no momento e permanente na prática, porque ninguém remove um piso que finalmente funciona. Duas falhas muito diferentes criam a pressão, e só uma delas tem a ver com cifras. Classifique a falha primeiro, depois coloque a exceção onde ela não possa se espalhar.

Divida a falha em duas antes de editar uma diretiva

Uma linha de log do servidor sobre ausência de cifra comum, ou sobre versão de protocolo não suportada, vem do canal de controle: as duas pontas não conseguiram concordar sobre como proteger a própria negociação. Uma linha do cliente dizendo que nenhum método de verificação do certificado do servidor está ativo vem de um lugar totalmente diferente, porque esse cliente não está checando quem respondeu. Trocar uma cifra de dados não faz nada pelo segundo caso, e acrescentar uma checagem de papel não faz nada pelo primeiro.

Pegue a primeira linha de falha de cada lado, não a última antes da desconexão, porque a última costuma ser consequência. Depois estabeleça qual arquivo o cliente realmente abriu: um perfil importado costuma existir duas vezes sob nomes exibidos diferentes, e editar a cópia que ninguém lê produz uma ausência de mudança convincente. Um processo em execução mantém as configurações com que começou, então um arquivo salvo não é um arquivo carregado. Os comandos abaixo mostram a negociação do cliente ao lado da visão do servidor sobre a mesma tentativa.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Um segundo listener é o lugar honesto para um piso mais fraco

Quando o dispositivo para em TLS 1.0 com canal de dados anterior a 2.5, o servidor precisa oferecer um piso menor para o canal de controle e uma cifra de dados que o cliente antigo reconheça. A diretiva de fallback existe exatamente para esse par, enquanto a lista de cifras mantém clientes modernos em suítes modernas. As duas diretivas pertencem ao listener, não a um usuário ou conexão, e nenhuma opção por cliente as estreita depois. É por isso que um dispositivo legado na porta principal é uma decisão sobre todo par que compartilha aquela porta.

Onde a plataforma permitir, rode o listener legado como instância própria numa porta separada, permita aquela porta apenas a partir do endereço do dispositivo e deixe o serviço principal em paz. Escreva por que o segundo listener existe, no arquivo que carrega a configuração dele, porque uma limpeza futura vai lê-lo como sobra. A separação só vale se o piso mais fraco terminar onde o dispositivo termina.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

O que um certificado antigo do provedor realmente quebra

O erro de verificação é uma vinculação de papel ausente: sem ela o cliente aceita qualquer certificado que encadeie a uma CA confiável, tenha ele sido emitido para um servidor ou não. Vincule o certificado ao papel de servidor primeiro, e trate a vinculação como requisito e não como botão de ajuste. Só um perfil que ainda falha depois desse passo tem um problema real de certificado.

Um certificado antigo do provedor cujo tamanho de chave ou algoritmo de assinatura não atende mais à política padrão do OpenSSL é o caso de uma mudança de nível de segurança limitada no canal de controle. Baixar o nível ali não desliga a verificação, e nunca deve ser combinado com CA vazia, verificação desativada ou nome de host não verificado. Mantenha a linha dentro do único perfil que precisa dela; exportar uma configuração OpenSSL relaxada globalmente entregaria o mesmo relaxamento a todo programa da máquina.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Leia os valores negociados, não o banner

Com verbosity 4, as duas pontas imprimem a versão TLS e a cifra do canal de controle que acordaram, e a cifra de dados da sessão. Leia essas linhas em vez do banner de inicialização, que relata sucesso e não os seus termos. Depois reconecte um cliente moderno ao listener principal e confirme que ele ainda cai numa suíte moderna, porque uma exceção que vazou para a configuração compartilhada aparece aqui primeiro. Os valores que você copiar viram a base da próxima revisão.

Teste o dispositivo antigo sozinho: ele deve conectar e deve ser a única sessão nos logs mostrando os parâmetros mais fracos. Se um segundo par também negociar a suíte antiga, a exceção é mais ampla do que o pretendido e a separação dos listeners não aconteceu de fato. Registre as duas observações, não só a conclusão.

Toda exceção precisa de um dono e de uma data

Uma exceção sem condição de remoção vira o padrão em silêncio, então coloque o dispositivo, o dono, o motivo e a data em que ela desaparece ao lado da configuração que ela justifica. Sem essa linha, o piso mais fraco sobrevive ao hardware que precisava dele.

Substituir o cliente, ou pedir ao provedor um perfil atual, é o resultado a buscar; a exceção é um adiamento e não um projeto. Quando o dispositivo se aposenta, remova o listener e o perfil na mesma mudança, para que nenhuma metade continue rodando. Nada disso torna os parâmetros antigos seguros, só impede que o limite de um dispositivo vire a base de todo mundo.