Por que o openssl rand não consegue criar a chave que o tls-crypt quer

O OpenSSL já está instalado, o host tem entropia, e gerar uma chave com ele parece o atalho óbvio. A saída será aleatória e secreta e completamente inutilizável, e a falha chega como erro do canal de controle em vez de algo que mencione um formato de chave. Essa desorientação é a parte cara, porque manda as pessoas inspecionarem suas cifras. O que a VPN lê é uma estrutura de arquivo específica, não um bloco arbitrário de bytes, e uma variante do recurso não pode ser produzida fora do servidor de forma alguma.

O que o arquivo no disco realmente precisa ser

Um arquivo de chave estática do OpenVPN é texto. Começa com uma linha de comentário que declara o que é, carrega dados hexadecimais em linhas de largura fixa e soma 256 bytes de material de chave. O OpenVPN o lê como o segredo compartilhado do canal de controle, não como um certificado, não como uma frase de senha e não como algo que uma biblioteca TLS reconheceria.

O mesmo tipo de objeto serve às duas funções do canal de controle. Com tls-auth, cada par também precisa de uma direção para que os pacotes de um lado não possam ser refletidos de volta para ele. Com tls-crypt, um único segredo compartilhado cifra e autentica o canal de controle nas duas direções, o que esconde o handshake além de protegê-lo.

Nada disso é conhecimento secreto, e o formato não é o ponto. O ponto é que o arquivo tem de coincidir exatamente com o que o leitor espera: cabeçalho, largura de linha, quebra de linha final e comprimento total. Um arquivo desviado em uma linha carrega como lixo ou falha de vez. Comparar dois pares byte a byte é, portanto, um primeiro teste legítimo, e é mais rápido do que ler qualquer um dos dois arquivos de configuração.

A forma suportada de criar um

Gere a chave estática simples com a ferramenta que vai consumi-la e depois faça referência a ela nas duas pontas:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

A grafia da opção mudou com o tempo: instalações antigas da era 2.4 usavam uma forma com um sinalizador separado antes do nome do arquivo, enquanto as compilações atuais aceitam a mais curta. De qualquer modo, o arquivo resultante é o mesmo tipo de objeto, então a verificação é se os dois pares têm bytes idênticos.

A segunda geração acrescenta uma estrutura que nenhum gerador externo consegue inventar. Uma chave de servidor é criada uma vez, e cada cliente recebe uma chave envolvida derivada dela:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

O que o cliente recebe não é a própria chave do servidor duplicada. É um objeto envolvido que carrega metadados que só o servidor pode desembrulhar, e é esse envolvimento que permite revogar um arquivo por dispositivo sem tocar em nenhum outro dispositivo. Mantenha a chave do servidor no servidor e trate-a como a raiz dessa confiança por dispositivo.

Onde os bytes feitos à mão quebram

Imprimir 256 bytes aleatórios como hexadecimal sob um cabeçalho correto daria, em teoria, um arquivo de chave estática que carrega. Continua sendo uma má ideia. Cada detalhe de formatação se torna uma chance de produzir material que falha ao carregar ou, pior, deixa dois pares com valores diferentes que só se revelam como falha de autenticação.

Nada equivalente é possível com a variante v2. Uma chave de cliente envolvida só existe como saída do processo de chave do servidor, e o servidor guarda o material necessário para desembrulhá-la. Um bloco aleatório será rejeitado ou simplesmente não conseguirá descriptografar, e nenhuma das duas mensagens mencionará aleatoriedade.

A compatibilidade de versões está por cima de tudo isso. A primeira geração precisa de uma versão que a suporte nas duas pontas, e a segunda precisa de novo de uma versão mais recente. Um cliente compilado antes de o recurso existir não consegue concluir um handshake com um servidor que só aceita material envolvido, e a falha que ele relata aponta para o canal de controle em vez da versão.

Rotacionar sem trancar todo mundo para fora

Rotacionar um único segredo compartilhado é um exercício de coordenação, não técnico. Cada cliente precisa do arquivo substituto em mãos antes de o servidor retirar o anterior, e qualquer máquina que ainda tenha o valor antigo falha no momento em que isso acontece. Não comece essa rotação no meio de um dia de trabalho.

Com o arranjo v2, a rotação é por dispositivo: emita uma nova chave envolvida para uma máquina e aposente a antiga só para aquela máquina. Esse é o argumento principal para migrar assim que todo cliente estiver em uma versão que o suporte.

As permissões de arquivo pertencem à mesma conversa. A chave deve ser legível apenas pela conta que executa o serviço, e não deve morar no mesmo repositório que os perfis que protege. A referência do OpenVPN 2.6 documenta as formas de geração e as seções de material de chave, o que é uma fonte melhor do que um comando copiado de uma postagem de fórum.