OpenVPN tls-ciphersuites versus tls-version-min: o que cada um impõe
Uma lista de suítes TLS 1.3 não limita a versão do protocolo, e show-tls só mostra o suporte local. Verifique a política, as suítes e os resultados negociados em separado.
Três fatos diferentes são reduzidos a uma linha na maioria das discussões de OpenVPN com TLS: o que a compilação do seu cliente consegue fazer, o que o perfil permite e o que a sessão realmente negociou. Uma lista curta de suítes TLS 1.3 responde apenas pela metade à pergunta do meio, e não diz nada sobre o piso da versão do protocolo. Percorra as verificações abaixo em ordem e pare na primeira que não se sustenta, porque cada verificação posterior pressupõe que as anteriores estão resolvidas.
Verifique a compilação antes de ler qualquer lista
Uma diretiva de configuração não pode adicionar suporte a protocolo a um binário que não o possui. Comece pelo banner de versão, que nomeia a biblioteca criptográfica compilada:
openvpn --version
Uma compilação 2.6 ligada ao OpenSSL aceita tanto tls-cipher quanto tls-ciphersuites. Uma compilação com mbed TLS não tem nenhuma seleção de suítes TLS 1.3, e o manual 2.6 marca tls-ciphersuites como opção do OpenSSL. Se o servidor for recompilado com outro backend, o mesmo perfil pode mudar de comportamento sem que uma única linha de configuração mude.
Enquanto está aqui, execute openvpn --show-tls e guarde a saída. É o inventário com que você comparará mais tarde, e é barato capturá-lo antes que alguém comece a editar perfis.
Escreva o banner e a lista no ticket de mudança, não numa janela de chat. Quando duas pessoas discutem se um cliente poderá oferecer uma suíte em seis semanas, a saída capturada resolve isso numa linha.
Mantenha os limites de versão separados das listas de cifras
No manual 2.6 estes são três controles, não um:
tls-cipherdefine a política de cifras para TLS 1.2 e anteriores, e é passado à lista de cifras do OpenSSL;tls-ciphersuitesseleciona suítes TLS 1.3;tls-version-minetls-version-maxlimitam as versões de protocolo que a conexão pode usar.
Portanto, uma lista de suítes TLS 1.3 cuidadosamente aparada não prova nada sobre uma versão mais antiga ainda ser permitida. Se o requisito é «apenas TLS 1.3», é o piso de versão que o sustenta, e a lista de suítes apenas restringe as escolhas dentro desse piso:
tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Esse par faz dois trabalhos. Apagar uma das linhas deixa a outra impondo menos do que você pensa, e é exatamente essa falha que toda esta verificação existe para pegar.
O canal de dados é um quarto controle. data-ciphers negocia a cifra simétrica dentro do túnel, e o resultado não diz nada sobre a versão TLS do canal de controle. Ver AES-256-GCM no resumo da sessão não é evidência sobre TLS 1.3 em nenhum sentido.
Leia o show-tls como um inventário local
--show-tls enumera as suítes suportadas pela biblioteca criptográfica à qual este binário está ligado, por ordem de preferência. Não é um relatório do gateway. O manual diz explicitamente que a lista vem da biblioteca local, o que significa que um portátil com OpenSSL 3.x e um router com uma compilação mais antiga imprimirão listas diferentes enquanto falam com o mesmo servidor.
| Evidence | What it actually describes |
|---|---|
--show-tls output | Capabilities of this client build and its library |
| Profile directives | What this attempt is allowed to offer |
| Session log line | What this one negotiation selected |
Suponha que um cliente suporte as suítes A, B e C e que uma sessão escolha B. Isso não estabelece nada sobre se o servidor permite A ou C, nem sobre se B é a sua única escolha permitida. Mantenha as três linhas separadas, e a maioria das discussões confusas de TLS resolve-se sozinha.
O inventário ainda vale a pena ser guardado. Quando uma sessão falha, comparar a lista da biblioteca com a do perfil diz se o cliente tinha alguma chance de oferecer o que o servidor queria. Também mostra se uma mudança de backend removeu silenciosamente TLS_CHACHA20_POLY1305_SHA256 do conjunto com que os clientes mais antigos contam — o tipo de regressão que aparece como um punhado de usuários que não conseguem ligar-se enquanto todos os outros não notam nada.
Pergunte ao gateway algo que ele possa responder
Se administra o serviço, inspecione a configuração efetiva da instância em execução em vez de um ficheiro no disco. O OpenVPN pode ter sido iniciado com outro caminho --config, pode carregar inclusões e pode não ter sido reiniciado desde a edição. A política do daemon em execução é a que os clientes encontram.
Se não o administra, peça ao operador os requisitos de cliente suportados ou um teste de aceitação delimitado. Uma tentativa recusada não é automaticamente uma suíte recusada: um piso de versão, verificações de identidade de certificado como remote-cert-tls, ou uma incompatibilidade entre tls-auth e tls-crypt podem terminar a troca antes de a seleção de suítes importar. Leia o erro do servidor antes de mudar a lista do cliente, porque «handshake failed» cobre quatro causas diferentes e apenas uma delas é uma incompatibilidade de cifra.
Apontar openssl s_client para a porta VPN também não reproduz a pergunta. O canal de controle corre dentro do próprio enquadramento do OpenVPN, portanto uma sonda TLS crua testa outro protocolo numa porta que espera outra coisa. Qualquer conclusão daí tirada é sobre a sonda, não sobre o túnel.
Registe dois resultados e mantenha-os separados
Uma sessão permitida recente produz uma linha do canal de controle que nomeia a versão do protocolo e a cifra selecionada, e uma linha separada do canal de dados que nomeia a cifra do túnel. Capture ambas com a versão do cliente e o nome do perfil, e anote qual instância do servidor respondeu:
openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt
Depois leia as duas linhas desse ficheiro em vez de as ler de memória. O par é a prova; um nome de suíte sozinho é uma preferência, e o limite de versão é uma afirmação separada sobre o que o servidor recusa.
Execute as verificações nesta ordem. Confirme a compilação e o backend com --version. Capture --show-tls antes de mudar qualquer coisa. Enuncie o piso de versão exigido separadamente da lista de suítes. Confirme a política efetiva da instância em execução com o seu proprietário. Observe uma sessão permitida e, se o plano permitir, uma tentativa recusada com uma versão mais antiga. Registe os resultados do canal de controle e do canal de dados como constatações separadas.
Se um cliente exigido não conseguir cumprir um novo mínimo, tome essa decisão de migração ou exceção explicitamente em vez de baixar em silêncio uma regra de aceitação não relacionada para que o lançamento pareça concluído.