Rastrear pacotes de controlo do OpenVPN: tls-auth antes de TLS

Uma falha de tls-auth é normalmente reportada como problema de handshake, e nunca o foi. O HMAC é verificado no pacote de controlo antes de qualquer processamento TLS, pelo que uma chave ou direção errada produz uma falha que parece um problema de certificado e é decidida duas camadas antes. Tratar o envelope como um objeto próprio encurta o diagnóstico: leia os campos, confirme que a verificação ocorre cedo e depois compare as três coisas em que ambos os extremos têm de concordar.

Leia o envelope pela ordem em que é construído

Um pacote de controlo transporta um identificador de sessão, o HMAC opcional do tls-auth, informação de repetição e confirmação, e um identificador de mensagem fiável, e depois vem a carga do tipo de mensagem. Quando a mensagem é uma mensagem de handshake, a carga é por acaso texto cifrado TLS. É toda a relação: o material TLS viaja dentro de uma mensagem que o envelope já protege. A referência do protocolo de rede do OpenVPN enumera os campos do canal de controlo nessa ordem.

A camada de fiabilidade confunde-se facilmente com criptografia. As confirmações, a retransmissão e o identificador de mensagem existem para que as mensagens de controlo cheguem uma vez e por ordem sobre um transporte não fiável. Não são autenticação, e um identificador de mensagem correto não prova nada sobre quem enviou o pacote.

Mantenha este agrupamento como conceito. Não é um diagrama de ordem de bytes e não basta para calcular uma etiqueta, porque os campos que entram no HMAC dependem da implementação, da versão e do modo.

Mostre que a verificação ocorre antes do handshake

Um recetor que possui a chave partilhada pode verificar o HMAC e descartar um pacote falsificado de imediato, sem alocar estado de handshake nem fazer trabalho de chave pública. A proteção cobre também os pacotes iniciais do handshake, e é exatamente por isso que uma chave errada aparece como ligação falhada e não como erro de autenticação tardio.

Aumente a verbosidade do daemon e observe o canal de controlo em vez do dispositivo tun:

openvpn --config /etc/openvpn/server.conf --verb 6

O que procura é uma falha de verificação HMAC do canal de controlo reportada ao nível do pacote, antes de qualquer alerta TLS. Um alerta TLS no registo significa que o envelope foi aceite e a falha passou para dentro, o que é outra investigação com outra correção.

O tratamento da direção também está aqui. Quando um ficheiro de chave estática é usado com tls-auth, os dois extremos assumem direções de chave opostas, e o protocolo usa essa divisão para que um pacote capturado não possa ser refletido de volta ao seu emissor. Inverter a direção mantém a chave idêntica e, ainda assim, falha em todos os pacotes. Altere um extremo de cada vez e depois reinicie ambos os daemons para que o par seja carregado em conjunto.

Alinhe chave, direção e digest em ambos os extremos

Três valores têm de coincidir e apenas um deles é o ficheiro. O conteúdo da chave estática tem de ser idêntico nos dois extremos, a direção tem de ser oposta e o digest usado para o HMAC tem de coincidir. Verifique a configuração antes de tocar no material da chave, porque uma única direção invertida explica mais falhas do que um ficheiro corrompido:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Gere o segredo partilhado com a ferramenta e não com um editor, e mantenha as permissões restritas:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Versões mais antigas aceitavam uma ordem de opções ligeiramente diferente para a geração de chaves, e os perfis escritos para essas versões ainda circulam. O ficheiro gerado é o mesmo tipo de objeto nos dois casos, pelo que a verificação é se ambos os extremos têm bytes idênticos, não qual grafia os produziu.

Não confunda tls-auth com tls-crypt. Ambos protegem o canal de controlo, mas o tls-crypt também o cifra e esconde o handshake dos observadores, e substitui a divisão de direções pelo seu próprio tratamento de chaves. Um perfil que usa um não interoperará com um par configurado para o outro, e nenhum ajuste de digest fecha essa lacuna.

Reproduza uma etiqueta apenas a partir do formato real

A reprodução exata ao byte é uma tarefa separada de executar uma VPN, e só funciona com as entradas reais: a implementação e a versão que construíram o pacote, o digest escolhido, a direção e os bytes reais, incluindo o identificador de sessão e a matriz de confirmações. Uma representação textual da lista de campos não são esses bytes.

O comprimento da etiqueta decorre do digest, por isso uma suposição de comprimento fixo quebra no momento em que alguém a altera. Faça o hash do pacote como a implementação faz, não como uma tabela num artigo de blog o apresenta, e compare com uma captura obtida do mesmo par em vez de com uma expectativa deduzida à mão.

Mantenha esse exercício longe dos perfis de produção. Nada na reprodução de uma etiqueta lhe diz se uma implantação deve ativar a proteção.

Reverta uma incompatibilidade sem remover a proteção

O teste tentador é apagar o tls-auth, ver a ligação funcionar e concluir que a chave estava errada. Essa resposta custa-lhe a proteção e não ensina nada sobre qual dos três valores divergia. Em vez disso, obtenha a configuração correspondente aprovada do lado do servidor e compare com ela.

Prepare a alteração para que seja reversível. Guarde a configuração e o ficheiro de chave anteriores do servidor, aplique o par corrigido, verifique que um cliente conclui o handshake e só então remova a cópia de segurança. Se os clientes falharem após a alteração, restaure os ficheiros anteriores em vez de improvisar uma terceira variante durante uma falha. A restauração deve ser um comando que já conhece antes de começar.

Por fim, lembre-se do que significa uma verificação aprovada. Prova que o par possui a chave partilhada, não que o seu certificado ou conta esteja autorizado, e não diz nada sobre a cifra negociada do canal de dados. A autorização e a proteção de dados são estabelecidas mais tarde, pelo que uma verificação limpa do envelope é um ponto de partida e não um veredito.