OpenVPN tls-crypt-v2: o que fazem a chave do cliente e o blob empacotado

Colar um perfil tls-crypt-v2 num ticket parece inofensivo até você contar o que o arquivo contém. A chave do canal de controle do cliente fica ao lado de uma cópia cifrada da mesma chave, e um terceiro objeto, a chave de empacotamento, nunca sai do servidor que aceita. Esses três respondem a perguntas diferentes sobre custódia, compartilhamento e desativação. Separá-los resolve a maioria das discussões de política antes de começarem.

O que o perfil realmente contém

A metade cliente do tls-crypt-v2 é uma chave mais uma cópia empacotada dela. O cliente usa a chave simples para proteger o canal de controle e entrega a cópia empacotada ao servidor durante a configuração, de modo que o servidor recupera a mesma chave sem armazenar uma cópia em texto claro por cliente. A chave de empacotamento torna essa recuperação possível e pertence apenas ao lado que aceita. Tudo abaixo decorre de onde esses três objetos vivem.

Leia a tabela por custódia, não por nome, e as consequências surgem sozinhas. Perder a chave de empacotamento é o evento caro, porque nada num perfil pode reconstruí-la e a recuperação honesta é reemitir o grupo. Um perfil vazado é mais barato, mas muito mais comum, porque as pessoas colam perfis em tickets acreditando que a cópia empacotada torna o arquivo seguro para compartilhar. As duas falhas exigem respostas diferentes, e é por isso que os objetos ficam separados.

Por que a cópia empacotada não é a história toda

Um perfil carrega o material utilizável do cliente junto com sua contraparte empacotada, então proteger a cópia para o servidor não diz nada sobre proteger o arquivo. O blob é seguro para transmitir e inseguro para publicar. Os metadados dentro dele ficam visíveis para quem receber o blob, incluindo quem depois ler o ticket em que ele foi colado.

Trate um perfil como credencial, não como exemplo de configuração. Um arquivo vazado dá ao portador uma identidade de cliente funcional até o servidor parar de aceitar essa identidade, e o empacotamento não faz nada quanto a essa janela. Emita um perfil por cliente para que a revogação continue sendo uma decisão de um único arquivo, e faça backup da chave de empacotamento separado da configuração do servidor que ela habilita. Nenhum dos dois hábitos conserta um perfil comprometido, mas ambos decidem com que rapidez o próximo será contido.

Onde o gancho de verificação fica no handshake

O gancho de verificação roda antes de a pilha TLS ser exposta, e sua tarefa é inspecionar os metadados transportados no blob empacotado. Ele recebe esses metadados mais um ambiente pequeno e documentado, e tem menos com que trabalhar do que um gancho de autenticação. Supor que ele vê nomes de usuário, estado da sessão ou variáveis de plugin é a forma habitual de escrever esse gancho mal. Leia a seção do manual do próprio gancho em vez de emprestar expectativas de outro gancho.

Seu status de saída é a decisão: um resultado diferente de zero recusa o cliente e um resultado zero deixa o handshake continuar. A política precisa, portanto, dizer o que acontece quando os metadados faltam, não podem ser analisados ou são inesperados. Escreva primeiro o caminho de recusa e depois decida quais valores são aceitáveis.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Essas duas linhas são a superfície de política no servidor: uma nomeia a chave de empacotamento, a outra nomeia o programa que julga cada cliente. Tudo o que é interessante vive no script, que merece controle de versão e a mesma revisão de qualquer outra regra de acesso.

Conta, certificado e chave de controle se desativam separadamente

A aceitação antecipada do canal de controle não é autenticação, porque acontece antes da verificação de identidade TLS e antes de qualquer autorização de conta. Desativar uma conta, revogar um certificado e recusar uma chave de controle do cliente são três ações com três mecanismos. Uma implantação que faz apenas uma delas tem uma lacuna, não uma política. Reconcilie as três deliberadamente e registre qual etapa exerce qual autoridade.

O tempo é a segunda distinção. Uma lista de aceitação alterada vale para novos handshakes, enquanto sessões já estabelecidas continuam rodando até algo terminá-las. Contar entradas na nova lista como prova de que as sessões antigas terminaram é como um cliente removido continua conectado por horas.

Autoridades não reconciliadas deixam dois buracos fáceis de encontrar na prática. Uma conta pode ser desativada enquanto sua chave de controle ainda abre um handshake, e um certificado pode ser revogado enquanto a política de metadados ainda admite o mesmo cliente. Ambos são o mesmo erro em lugares diferentes, porque um operador tratou uma única lista como toda a autoridade. Coloque as três listas lado a lado no momento da remoção e o erro fica visível.

Emitir e revogar um perfil

Emitir é a metade fácil: crie a chave do cliente no lado que aceita, entregue o perfil a exatamente um proprietário, mantenha o material de empacotamento restrito e execute o mesmo programa de verificação em cada servidor que aceita. A admissão barata é uma propriedade do grupo inteiro, não do host mais novo. Um segundo servidor com um script mais antigo ou mais frouxo se torna silenciosamente o caminho mais fraco da implantação.

A revogação exige as três etapas numa ordem deliberada. Recuse o cliente no gancho de verificação para que os novos handshakes falhem, revogue seu certificado se houver uma PKI em uso e desative a conta para que a autorização posterior não tenha o que autorizar. Em seguida, encerre as sessões que a aceitação antiga permitia, pois elas não perceberão nenhuma das três. Ensaie a sequência num cliente que você possa se permitir quebrar.

Metadados num perfil são uma entrada para essa política, não a prova de que o controle de acesso já existe. O documento de design do OpenVPN 2.6 descreve os objetos e a fronteira que eles traçam, enquanto a aplicação continua com o operador.