Registro do OpenVPN: cifra do canal de controle contra cifra do canal de dados

Uma linha de registro que nomeia DHE-RSA-AES256-SHA não é um resumo de toda a conexão. Ela pertence ao handshake TLS que protege o canal de controle, e o tráfego dentro do túnel pode ser cifrado com algo totalmente diferente. Apresentá-la como a cifra de dados da VPN é o erro a evitar.

Dois resultados importam, e eles respondem a perguntas diferentes. Um é a suíte TLS negociada para o canal de controle; o outro é a cifra de dados dos pacotes que o túnel transporta.

Dois resultados, duas perguntas

O canal de controle transporta o handshake e as mensagens de gerenciamento entre os pares. Sua cifra é escolhida pela pilha TLS, então o nome segue as convenções TLS. O canal de dados transporta o tráfego do usuário e é configurado pela negociação de cifra do próprio OpenVPN.

Decida qual pergunta você está respondendo antes de ler qualquer uma das linhas. Se o túnel está cifrado e se o handshake é forte não são a mesma pergunta.

Um trecho de registro que mostra as duas linhas é o útil. Leia a linha de controle para a versão e a suíte TLS, e a linha de dados para o algoritmo que realmente protege a carga útil.

Decodifique o nome da suíte TLS no próprio contexto

Em um nome histórico no estilo OpenSSL como DHE-RSA-AES256-SHA, cada componente descreve uma decisão diferente. DHE é o acordo de chaves Diffie-Hellman efêmero, RSA é o método de autenticação, AES256 é AES-256 no modo CBC para os registros TLS, e SHA é o MAC de registro baseado em SHA-1.

O último componente não é uma impressão digital do certificado, e lê-lo como tal é um erro comum. O nome também não informa a versão do protocolo por si só, porque TLS 1.3 usa um esquema de nomes totalmente diferente. TLS_AES_256_GCM_SHA384 segue essa forma mais nova, em que o hash final faz parte da construção da suíte em vez de ser uma escolha de MAC. Aplique a leitura por componentes apenas ao estilo de nomes mais antigo.

A referência de suítes do OpenSSL associa esses nomes às suas definições se algum componente não for familiar.

Leia o resultado do canal de dados para o tráfego transportado

Para o tráfego transportado, leia a linha do canal de dados da mesma sessão. Uma lista data-ciphers na configuração é um conjunto permitido, não a prova de que um algoritmo específico foi negociado. O registro anota a escolha; a configuração lista o menu.

Uma cifra AEAD como AES-GCM traz a própria verificação de integridade, então um HMAC separado do canal de dados não faz parte desse caminho.

A diretiva auth não melhora TLS, certificados nem a cifra de dados. Ela seleciona um digest para as partes do protocolo que ainda usam um, e com uma cifra de dados AEAD não há HMAC de dados separado a configurar.

Mantenha as verificações de identidade fora do resultado da cifra

O algoritmo de assinatura do certificado, a validação da cadeia de confiança e a verificação do nome do par são mais três propriedades sobre as quais um nome de cifra não diz nada. Um certificado expirado falha, por mais forte que seja a suíte. Um nome de servidor que não corresponde falha da mesma forma. Corrigir um ajuste de digest no perfil não conserta nenhuma das duas coisas.

Mantenha essas verificações nas notas de revisão ao lado do resultado da cifra, sem fundi-las nele.

Registre os resultados negociados da sessão atual

Pegue os resultados da conexão atual e registre junto as versões do cliente e do servidor. Um registro somente de acréscimo pode conter a linha de uma sessão antiga, e citá-la como atual é como um problema corrigido parece persistir.

Para uma revisão de políticas, entregue ao responsável pela configuração a versão e a suíte TLS negociadas, a cifra de dados escolhida e as configurações de validação de certificados juntas. Altere essa camada e depois leia um registro novo para confirmar os novos valores negociados.